* First attempt at aliases for require
* test+initial support for const x=require
* 1st round of baseline improvements
* 2nd round of baseline updates
* support property access after require
* check @type tag on require
* forbid expando missing namespaces on aliases
taken from #39558 as soon as it was created
* accept error baselines that are good, actually
* Scribbling on d.ts emit code
* use getSpecifierForModuleSymbol
* hideous hack for module.exports of aliases
* Fix module.exports.x --> export list emit
* fix isLocalImport predicate
* require only creates aliases in JS
* re-handle json imports
* update fourslash baseline
* Cleanup in the checker
1. Simplify alias resolution.
2. Simplify variable-like checking.
3. Make binding skip require calls with type tags -- they fall back to
the old require-call code and then check from there.
I haven't started on the declaration emit code since I don't know what
is going on there nearly as well.
* Function for getting module name from require call
* First round of cleanup plus a new test
Found one missing feature, not sure it's worth adding.
* more small cleanup
* more cleanup, including lint
* use trackSymbol, not serializeTypeForDeclaration
* Code review comments, plus remove unneeded code
Ad-hoc type reference resolution for `require` isn't needed anymore.
* find all refs works
* remove old ad-hoc code
* make it clear that old behaviour is not that correct
* update api baselines
* remove outdated comment
* PR feedback
1. Fix indentation
2. Add comment for exported JSON emit
3. Add test case for nested-namespace exports.
* add a fail-case test (which passes!)
* Use isUncalledFunctionReference for aliases too
Fixes bogus deprecated notices on imports of functions with deprecated
overloads, but with some non-deprecated overloads.
Fixesmicrosoft/vscode#104238
* Just check all declarations, don't call isUncalledFunction
* Handle unresolved baseType when trying to get completions for static member
Fixes #38067
* Update src/services/completions.ts
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* correct the condition
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Hack everything together
* Add test
* Remove realpath from program
* Ensure symlinked directories are directories
* Revert unnecessary change
* Update baselines
* Use host program realpath on AutoImportProviderProject files before program creation
* Which fixes hasRoots() too
* Apply suggestions from code review
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Lint
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Fix#37948
* Fix formatter skipping tab/space fixup on comments, handle trailing commas in list closing line count.
Fixes#37944
* Add newline between imports and main body of new file in moveToNewFile
Fixes#37941
* Update baseline (probably broken before?)
* Fix find-all-references on `undefined`
* Show references in input files in baseline
* Inline commentEachLine
* firstOrUndefined doesn’t take undefined
* Fixes searches for export * as 'identifier'
Fixes#39006
* Fix the context span to export declaration (was incorrectly set to sourceFile in prev commit)
* Type `this` in more constructor functions
Previously, `this: this` in constructor functions only when there was
an explicit `@constructor` tag on the function. Now, `this: this` for
any function that's known to be a constructor function.
This improves completions inside constructor functions; also note that
previously the compiler *did* type `this: this` inside methods of constructor
functions, so this fix makes us more consistent. This is reflected in
the large number of baselines that improve.
The fix is a simple switch to `isJSConstructor`, which is the standard
way to detect constructor functions. I'm not sure why the original PR
didn't use this method.
I remember discussing this limitation in the original bug, #25979, and
I guess I decided that it made sense. But I was heavily primed by the bug's
framing of the problem in terms of `noImplicitThis`, which *should*
require an explicit `@constructor` tag.
With better typing comes better detection of `@readonly` assignment; I
had to fix the readonly detection code to use `isJSConstructor` as well.
* Remove `Add @class tag` fix for noImplicitThis.
The new rules mean that it never applies. It's possible that it should
apply to functions like
```js
function f() {
this.init()
}
```
In which `init` is never defined, but I think this program is incomplete
enough that not offering the fix is fine.
* Fix precedence of `@this`
Previously, both `@class` and `@this` in a jsdoc would cause the `@this`
annotation to be ignored. This became a worse problem with this PR,
because `this` is correctly typed even without the annotation.
This commit makes sure that `@this` is checked first and used if
present.
* Mark @typedef as a type declaration
This is only important right now for marking uses of deprecated tags due
to the way that deprecated type references are computed. But I'm
surprised it hasn't caused problems elsewhere.
Fixes#39466
* Also mark @callback and @enum
Requires making name lookup in isTypeDeclarationName smarter, but this
is only used by services, so shouldn't be too performance sensitive.
* Node-based @deprecated checks
Switch the checker to syntactic checks for `@deprecated` on
declarations. This requires a bit more checking of declarations in the
checker at times, but it
1. Gets rid of work, and a symbol flag, in the binder.
2. Skips work in the checker unless there is a `@deprecated` tag.
3. Makes it fairly simple to only issue errors on particular signatures
of overloaded functions.
* remove in-progress comment
* remove unused isTypeDeclaration
* ❤️ lint
* support jsx and tagged template functions
* Support decorators too
