Code completion crashes when localStorage, postcss-object-fit-images, or gulp-watch packages are imported #27857
Copy link
Copy link
Closed
Labels
BugA bug in TypeScriptA bug in TypeScriptCrashFor flagging bugs which are compiler or service crashes or unclean exits, rather than bad outputFor flagging bugs which are compiler or service crashes or unclean exits, rather than bad outputDomain: LS: Completion ListsThe issue relates to showing completion lists in an editorThe issue relates to showing completion lists in an editorFixedA PR has been merged for this issueA PR has been merged for this issue
Milestone
Description
TypeScript Version: 3.2.0-dev.20181011
TypeScript Version: 3.1.3
Search Terms: code completion, auto import, intellisense
Code
You can check out this repo to reproduce the issue: repo link
If any of the following dependencies are imported in the project the code completion feature crashes: localStorage, postcss-object-fit-images or gulp-watch. Without them the feature works just fine.
Expected behavior: code completion works when the mentioned dependencies are imported
Actual behavior: code completion crashes if any of the following dependencies are imported in the project: localStorage, postcss-object-fit-images or gulp-watch
Related Issues: #27640
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
BugA bug in TypeScriptA bug in TypeScriptCrashFor flagging bugs which are compiler or service crashes or unclean exits, rather than bad outputFor flagging bugs which are compiler or service crashes or unclean exits, rather than bad outputDomain: LS: Completion ListsThe issue relates to showing completion lists in an editorThe issue relates to showing completion lists in an editorFixedA PR has been merged for this issueA PR has been merged for this issue
Activity
DanielRosenwasser commentedon Oct 25, 2018
Nathan Shively-Sanders (@sandersn) can you verify whether this fixes #28133?
sandersn commentedon Oct 25, 2018
No, it does not fix it. Sounds similar, but there's no module.exports merge.
And the crash doesn't go down the wrong branch of getTypeOfSymbol, although that's not necessarily indicative.
sandersn commentedon Nov 1, 2018
One important trigger of the problem is that the two export assignments differ: one is an alias and the other is a value. The resulting symbol merges, unlike in TS, ending up with the flags
Alias | Property | ExportValue | ValueModule. Now I need to track down where this makes the alias creation go wrong.sandersn commentedon Nov 1, 2018
An alias with Value flags blocks alias resolution, which is why checker.resolveExternalModuleSymbol incorrectly returns an alias (which getDefaultExportInfoWorker tries to resolve itself, but fails).
The fix might be to allow only all-Alias or all-Value module-export assignments. I'll have to see whether this causes a bunch of real-world failures though.
sandersn commentedon Nov 1, 2018
Never mind; resolveSymbol has a special-case explicitly for assignment declarations. I just need to use
SymbolFlags.Assignment | SymbolFlags.Aliaswhen bindingmodule.exports = *EntityName*.zfeher commentedon Nov 8, 2018
Nathan Shively-Sanders (@sandersn) I've just checked the issue in our full project too with the current build: typescript@3.2.0-dev.20181107 and the auto complete seems to be working \o/
Thank you for fixing it.