Fixes 44167, but also two other things:
* On an import/export, climb upto the declaration, and use
`SemanticMeaning.Type` if it's a `type` only import/export.
* Add a `test.rangesInFile()` to fourslash, so it is easy to do multiple
files in one test without an awkward filter (which was done in one
more test).
* Make export-module and reference maps invertible
Right now, we're enumerating all the entries to find out which keys map
to a corresponding value. By maintaining a two-way map, we can convert
this linear search into a map lookup and skip allocation of many, many
iterator results.
* Fix lint error
* Add some explanatory comments
* Rename, drop type parameters, and add readonly variant
* Simplify member list
* Fold non-exporting behavior into custom map type
* Don't attach declarations to symbols in mapped types with 'as XXX' clauses
* Add test (and tweak comment)
Co-authored-by: Eli Barzilay <eli@barzilay.org>
* Always issue cannot find name did-you-mean error
This PR issues "cannot find ${name}, did you mean ${name}" errors for
identifiers and propery access expressions in JS files *without*
`// @ts-check` and without `// @ts-nocheck`. This brings some benefits of
Typescript's binder to all Javascript users, even those who haven't
opted into Typescript checking.
```js
export var inModule = 1
inmodule.toFixed() // errors on exports
function f() {
var locals = 2
locale.toFixed() // errors on locals
}
var object = {
spaaace: 3
}
object.spaaaace // error on read
object.spaace = 2 // error on write
object.fresh = 12 // OK, no spelling correction to offer
```
To disable the errors, add `// @ts-nocheck` to the file. To get the
normal checkJs experience, add `// @ts-check`.
== Why This Works ==
In a word: precision. This change has low recall — it misses lots
of correct errors that would be nice to show — but it has high
precision: almost all the errors it shows are correct. And they come
with a suggested correction.
Here are the ingredients:
1. For unchecked JS files, the compiler suppresses all errors except
two did-you-mean name resolution errors.
2. Did-you-mean spelling correction is already tuned for high
precision/low recall, and doesn't show many bogus errors even in JS.
3. For identifiers, the error is suppressed for suggestions from global files.
These are often DOM feature detection, for example.
4. For property accesses, the error is suppressed for suggestions from
other files, for the same reason.
5. For property accesses, the error is suppressed for `this` property
accesses because the compiler doesn't understand JS constructor
functions well enough.
In particular, it doesn't understand any inheritance patterns.
== Work Remaining ==
1. Code cleanup.
2. Fix a couple of failures in existing tests.
3. Suppress errors on property access suggestions from large objects.
4. Combine (3) and (4) above to suppress errors on suggestions from other, global files.
5. A little more testing on random files to make sure that precision
is good there too.
6. Have people from the regular Code editor meeting test the code and
suggest ideas.
* all (most?) tests pass
* NOW they all pass
* add tonnes of semi-colons
* restore this.x check+add a test case
* make ts-ignore/no-check codefix work in unchecked js
* Issues errors only in the language service
* add a few more tests
* fix incorrect parentheses
* More cleanup in program.ts
* Improve readability of isExcludedJSError
* make diff in program.ts smaller via closure
* Switch unchecked JS did-you-mean to suggestion
Instead of selectively letting errors through.
* undo more missed changes
* disallow ignoring suggestions
* Issue different messages for plain JS than others
Straw text for the messages, I just changed the modals to avoid name
collisions.
Function extraction failed when using two identical `TypeLiteral`s ---
the problem is that the parameters' `.type.members` are shared in their
two occurences in the resulting code, and when the formatter bangs
position properties on the second, it's actually changing the first too.
* `typeToAutoImportableTypeNode`: wrap in `getSynthesizedDeepClone` to
avoid the offeding sharing.
* `getSynthesizedDeepCloneWorker`: add optional nodes/token visitors so
it doesn't skip cloning the above.
* A few very minor tweaks which I saw when tracing this (comment update,
two `!`s).
Fixes#44301
* Make handleDtsMayChangeOf void-returning
Right now, it always returns false. This seems important, since
otherwise it would stop graph traversals prematurely. It took me a
while to figure that out though and I thought it might be clearer if it
were simply void-returning.
I've kept the behavior the same, except in
`forEachReferencingModulesOfExportOfAffectedFile`, where it seemed like
never enqueueing new references was a mistake.
* Make forEachFileAndExportsOfFile void-returning
As far as I can tell, it could only return `false`.
* Add cache invalidation for node_modules, config, and preferences changes
* Share watches with closed script info
* Update API baseline
* Small adjustments for fewer object allocations
* Document overloaded return value
* Update baselines
* Store isAutoImportable separately from modulePaths
* Add back missing return
* Return wrapped watcher instead of underlying one
* Make user preferences part of the cache key instead of implicitly clearing in editor services
* Fix missed merge conflict
* Fix discovery of more pnpm symlinks
* Add some tests
* Never show pnpm paths in auto imports, even if there’s no other path
* Import statement completions can return none
* Fix tests
* Add failing test showing poor symlink cache reuse
* Fix test, fails for right reasons now
* Preserve cache built up during program creation, then fill in with program resolutions
* Remove obsolete comment
* Remove obsolete type assertion
* Revert fully filtering out ignored paths
As of 3c32f6e154, a line separator is
added between nodes if the nodes are not synthetic and on separate
lines. This it push s wrong and previously only happened if the non-synthetic
nodes were on different lines but had the same parent.
Fixes#44068.
* Add test showing how setting strict is not preserved in tsbuildinfo
Test for #44305
* Handle strict flag when writing tsbuildinfo
Fixes#44305
* Apply suggestions from code review
Co-authored-by: Daniel Rosenwasser <DanielRosenwasser@users.noreply.github.com>
Co-authored-by: Daniel Rosenwasser <DanielRosenwasser@users.noreply.github.com>
* Add test case for 'useUnknownInCatchVariables'.
* Add new 'useUnknownInCatchVariables' flag.
* Accepted baselines.
* Add test for catch variable explicitly typed as 'any'.
* Accepted baselines.
* Move option under 'strict'.
* Accepted baselines.
* 'useUnknownInCatchVariables' is strict in command line help.
* Update the category descriptions for the tsconfig options
* Gets tests green
* Whitespace change
* Drop command line options from --init
* Go back to the old re-build baseline
* Fix numbers
* Remove formatting options from --showconfig
* Dpon't show output formatting changes in showConfig
* Update baselines
* Update baselines
* Tests to baseline tsserver instead of checking
Also ensures inferred and auto import projects have name per project service
* Log structureIsReused value
* more baselines
