* Initial implementation of variadic tuple types
* Accept new baselines
* Handle variadic elements in tuple type inference
* Special case inference between tuples with matching structure
* Restore check that rest element is last element
* Handle variadic tuples in relationship checking
* Accept new baselines
* Infer readonly constraints when inferring from readonly tuples
* Fix lint issues
* T assignable to readonly [...T] and [...T] assignable to T
* Consistent tuple normalization
* Create variadic tuple types from array literal expressions
* Accept new baselines
* Array literals have tuple types when contextual type is readonly
* Accept new baselines
* Optional elements before required elements become required elements
* Update logic for rest parameters and spread arguments
* Revert special case of contextual readonly array type
* Accept new baselines
* Fix lint issue
* Switch entirely to createTupleType based on element flags
* Don't infer readonly tuple types when inferring to variadic elements
* Handle mapped types applied to generic tuple types
* Handle constraint of indexed access type with generic tuple type
* Accept new baselines
* Address CR feedback
* Simplify indexed access types involving generic tuple types
* Propagate checkMode into getSpreadArgumentType
* Guard against missing globalArrayType
* Inference to [...T, ...U] based on implied arity of T
* Accept new baselines
* Add tests
* Emit .d.ts from tests
* Address CR feedback
* Start experiment
* Add logging
* Go back to a single program
* Fix forEachExternalModuleToImportFrom
* Move auxiliary program to language service
* Add logging
* Don’t use resolution cache
* Fix(?) containingProjects for ScriptInfo in auxiliary program
* Fix ScriptInfo project inclusion
* Add test for default project of auto-importable ScriptInfo
* Add fourslash server test
* Don’t create auto import provider inside node_modules
* Add monorepo-like test
* WIP
* Naively ensure autoImportProvider is up to date after package.json change
* Start limiting when auto update provider gets updated
* Respond to changes in node_modules
* Don’t create auto-import provider until a file is open that would use it
e.g., don’t create them during cross-project find-all-refs
* Clean up naming, @internal marking, and fix empty project creation bug
* Drop devDependencies, include peerDependencies
* Add additional compiler options
* Fix interaction with importSuggestionsCache
* Move option to UserPreferences, allow inclusion of devDependencies
* Don’t filter out peerDependencies
* Watch unparseable package.jsons
* But don’t filter packages out due to an invalid package.json
* Update test
* Don’t use autoImportProvider in codefixes where it can never be used (or any refactors)
* Add CompletionEntry property for telemetry
* Add assertion for isPackageJsonImport to fourslash
* Fix missing pushSymbol argument
* Add isPackageJsonImport to tests and API baselines
* Fix unit test
* Host auto import provider in new Project kind
* Fix InferredProject attaching on AutoImportProvider-included files, load eagerly
* Update Public APIs
* Simplify PackageJsonCache host
* Remove unneeded markAsDirty
* Defer project finished event until after AutoImportProvider is created
* Make AutoImportProviderProject always report isOrphan = true
* Close and remove AutoImportProviderProject when host project closes
* Don’t set pendingEnsureProjectForOpenFiles
* Use hasAddedOrRemovedFiles instead of hasNewProgram
* Use host-wide watchOptions for package.json watching
* Add to `printProjects`
* Clean up
* Get autoImportProvider directly from LanguageServiceHost
* Clean up
* Clean up
* Close auto import provider on disableLanguageService
* Move AutoImportProvider preload to project updateGraph
* Clear auto import suggestion cache when provider program changes
* Fix tests
* Revert yet-unneeded change
* Use projectService host for module resolution host
* Don’t re-resolve type directives if nothing has changed
* Update src/server/project.ts
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Use ts.emptyArray
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
This makes the language service treat .js files inside node_modules as
part of the parent project, so that you can view the same errors in the
editor as you see in the baselines.
Also update a comment in the parser that I missed in an earlier PR.
* Add deprecated related feature
* Add more support
* fix navtree
* Add identifier check
* Add more deprecated
* fix crash
* fix more crash
* fix crash
* improve diagnostic
* avoid new tag
* avoid tags
* accept baseline
* Check deprecated in binder
* fix baseline
* fix jsdoc cache
* fix incorrect fix
* Avoid useless changes
* Accept baseline
* Add tests
* fix perf
* fix public api
* Adjust deprecated mark on qualifed name
* Revolve alias symbol
* Use modifier flags insted of symbol props
* Fix modifier flag resolve
* Make lint happy
* Fix crash
* fix crash
* Add cached utils function
* Accept baseline
* Add more tests
* try pinning octokit again
* Avoid tests
* Use utils some
* Deprecated perf test (#3)
* check valueDeclaration only
* check without modifierFlags
* donot check alias
* use cached tag
* remove call to jsdoc
* use deprecated tag
* revert changes
* Revert mission changes
* use node flags
* cache result
* cache
* avoid modifier flags
* Opts
* fix jsdoc include modifier
* fix tests
* fix again
* use symbol flag
* set @octokit/rest back to latest
* fix trailing spacel int
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
Outside of JSDoc comments, postfix-? is parsed at lower precedence than
the `?` of conditional types, and a postfix-? inside a tuple type
results in the type being marked optional.
This PR changes JSDoc parsing to behave the same way, which means that
1. Conditional types are allowed in JSDoc. Fixes#37166.
2. Tuple types' postfix-? syntax is interpreted correctly in JSDoc.
Fixes#38747.
The breaking change is that a postfix-? type followed by another postfix type,
like `[]` or `!`, is parsed as a conditional type. [Postfix-? is not
common](https://github.com/microsoft/TypeScript/issues/37166#issuecomment-612274456),
so this is an acceptable breaking change.
A postfix-? type `T?` is still parsed everywhere else and treated as `T | null`.
* Refactor node factory API, use node factory in parser
* Move UnparsedSource nodes to factory
* Make most Node properties read-only
* Make pos/end/parent and JSDoc 'comment' read-only
* Update function/constructor-type factories
* Remove treeStateObserver
* Simplify Debug.deprecate
* Remove unused factory methods, simplify lazy factory methods
* Fix base factory used for source file updates
* Update test baseline due to merge from master
* Rename factory methods to be more consistent (#39058)
* If there is no changes to folder structure when watching directories recursively, send the updates to fileNames only
Fixes#37994
* Ignore excluded directories from wild card watching
* Testcase showing that renaming file with non sync directory watcher displays correct error in the end
Testcase for #38684
* Syntax only server creates inferred project with all the open files with noResolve and can handle semantic operations
* No Watching
* Disable tests
* Add and fix tests
* Only support selected commands
* Revert "Disable tests"
This reverts commit 90d8a966eb.
* Dont log request details for unsupported commands
* Add declaration emit error and checking for circularly referential unions produced by recursive conditionals
* Allow indexed accesses to produce alias symbols on types
* Add test that still triggers the declaration emit error
* Fix spelling
I ran into it and the comment at the top tripped me, then I proceeded to
simplify the code. Patched a bit more of the function to make sure that
the indentation doesn't change, and added tests.
Two problems are fixed:
* `isArgumentsLocalBinding` did only `PropertyAccessExpression`, now
it's also doing `PropertyAssignment` (doesn't affect other files,
since it's only used in the emitter).
* `visitShorthandPropertyAssignment` should call `visitIdentifier` on
the synthesized id. (For completion it might be better to make it
visit the the original?)
Fixes#38594.
Neither `x[0]` nor `x[(0)]` should be dynamic names. Previously, the
latter was because `isDynamicName` didn't skip parentheses.
Since the binder treats dynamic names in property assignments as
assignment declarations, this incorrectly tried to create a binding for
expressions like `x[(0)] = 1`.
This caused an assert because `x[(0)]` would not take the dynamic name
code path during binding (`hasDynamicName` returned false), but the
normal code path for static names.
* fix(38750): create unique names for keywords and re-export them with original names
* Serialize (noncontextual) keyword named namespace members with export declarations in both declaration emitters
* Add exhaustive keyword emit test for js declaration emitter and fix it up
Co-authored-by: Alexander T <alexander.tarasyuk@outlook.com>
