* Initial implementation of string template types
* Accept new API baselines
* Accept new baselines
* Unified checking for large cross product union types
* Accept new baselines
* Ensure errors from union type resolution are reported
* Accept new baselines
* Compute constraints for string template types
* Support `as T` clause in mapped types
* Accept new API baselines
* Add missing semicolon
* Add checking of `as T` clauses
* Support casing modifiers in string template types
* Accept new baselines
* Bump keyword maximum length
* fix anders
* Revert "fix anders"
This reverts commit b3178d4618.
* Properly handle 'as T' clause with keyof for mapped type
* Fix lint error
* Single character inferences and anchored end span matching
* Fewer array copy operations in template literal type resolution
* Handle cases where 'as T' maps multiple properties onto one
* Fix lint error
* Store key type instead of type mapper in MappedSymbol
* No constraint on `in T` type when `as N` clause present
* Rename from TemplateType to TemplateLiteralType
* Accept new API baselines
* Add tests
* Accept new baselines
* Address CR feedback
* Accept new API baselines
Co-authored-by: Erich Gamma <egamma@microsoft.com>
* Add see tag parser
* add baseline
* fix symbol resolve
* add more case
* fix unittests
* improve tests and parser
* accept baseline
* Adopt package-lock.json and npm ci
* Add a workflow to update package-lock.json daily
* Git ignore package-lock.json and forcibly update in workflow
* Update bot email address
* Delete extra npm update
* Update package-lock.json
* Add compactDisplay and signDisplay to NumberFormatOptions (#40039)
* Fix typo in (Readonly)Set.keys comment (fixes#40164) (#40176)
* fix(26325): use a unique name for reserved words in 'constructor like' function name (#39684)
* fix(25770): add diagnostic message for the possible mapped type used as an index (#39973)
* fix(31046): add new diagnostic message for incompatible constructor signature (#40073)
* Update package-lock.json
* Update package-lock.json
* Add rename support
* Accpet baseline
* wip
* fix anders
* Revert "fix anders"
This reverts commit b3178d4618.
* Fix call hierarchy item serialization and server tests (#40348)
* Avoid error
* accept baseline
* Add more tests
* Add signature name resolve
Co-authored-by: Andrew Casey <andrew.casey@microsoft.com>
Co-authored-by: TypeScript Bot <typescriptbot@microsoft.com>
Co-authored-by: Neil Kistner <neil.kistner@gmail.com>
Co-authored-by: cherryblossom000 <31467609+cherryblossom000@users.noreply.github.com>
Co-authored-by: Alexander T <alexander.tarasyuk@outlook.com>
Co-authored-by: Erich Gamma <egamma@microsoft.com>
Co-authored-by: Andrew Branch <andrewbranch@users.noreply.github.com>
* Consistently error when rest element isn't last in tuple type
* Add regression test
* Accept new baselines
* Stricter circular recursion check in type inference
* Revert "Stricter circular recursion check in type inference"
This reverts commit 80e6df6230.
* Revert "Accept new baselines"
This reverts commit 355706dadc.
* Accept new baselines
* Passing --checkJs always sets --allowJS
Even if you have `"allowJs": false`. This is not a useful combination.
Changing this makes the compiler more friendly and easier to describe.
* only set allowjs if not explicitly set
* remove stray newline
* restore bad config error
* use an accessor function instead
* Fix crash intersecting dynamic import w/esModuleInterop
The dynamic import shim creates a symbol without some properties that
the intersection-creating code assumes are present as of #38673.
This PR adds the smallest possible set of properties to avoid the crash.
I'm not sure what others would be good to add.
* Use symbol's declarations instead
* Fix getResolvedMembersOrExportsOfSymbol instead
* comment from code review
* Don’t offer to extract export assignment
* Terminate unterminated literals when extracting them
* Add test with regular expression ending in backslash
* Add test for string literal ending in backslash
* Remove unused parameter default
When handling an array type, the lookup should use the position index
instead of the identifier name.
Also uncomment the tests in the `staticFieldWithInterfaceContext.ts`
test which failed because of this bug.
Fixes#40158.
The commonjs-specific code for resolving access expressions on `require`
assumes a fake commonjs export. For real exports, it needs to call
resolveSymbol since it's outside the normal alias-resolving
infrastructure.
From the user tests:
```js
const x = require('y').z.ka
```
would cause the crash because I forgot to call
getLeftMmostPropertyAccessExpression in one place.
Note that this doesn't fix the alias, it just stops the crash.
* Modify test harness so it can report underlying issue, fix small parent pointer issue
* Fix underlying export asignment check issue and fix lints
* Ensure class/function duplicate declaration errors are reported regarless of which is encountered first
* Ensure flag conflict errors are reported regardless of which declaration is encountered first
* 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!)
* Support recursive conditional types
* Accept new API baselines
* Accept new baselines
* Simplify recursive type tracking in type inference
* Accept new baselines
* Add tests
* Accept new baselines
* Revise recursion tracking in type inference
* Revise tests
* Accept new baselines
* Add more tests
* Accept new baselines
The exception thrown by Node.js's fs.statSync function contains a stack
trace that can be expensive to compute. Since this exception isn't used
by fileSystemEntryExists, we can safely set Error.stackTraceLimit to 0
without a change in behavior.
---
A significant performance improvement was noticed with this change while
profiling tsserver on packages within a proprietary monorepo.
Specifically, my team saw high self time percentages for Node.js's
uvException and handleErrorFromBinding internal functions. These
functions are executed within fs.statSync when it fails to find the
given path.
https://user-images.githubusercontent.com/906558/90183227-220cb800-dd81-11ea-8d61-f41f89481f46.png
fs.statSync: https://github.com/nodejs/node/blob/v14.4.0/lib/fs.js#L1030-L1037
handleErrorFromBinding: https://github.com/nodejs/node/blob/v14.4.0/lib/internal/fs/utils.js#L254-L269
uvException: https://github.com/nodejs/node/blob/v14.4.0/lib/internal/errors.js#L390-L443
## Measurements
After adding Error.stackTraceLimit = 0, we saw:
- For a large configured project with 12,565 files, tsserver reached the
projectLoadingFinish event 48.78% faster. (~46.786s vs ~31.447s)
- For a medium project with 7,064 files, tsserver was 25.75% faster.
(~20.897s vs ~16.618s)
- For a small project with 796 files, tsserver was only a negligible
3.00% faster. (~3.545s vs ~3.442)
Measurements were taken on macOS 10.15.6, Node.js 14.4.0, and a recent
master commit of TypeScript (610fa28d). The average of 3 runs before and
after this change were taken.
I would normally include .cpuprofile and isolate-*-*-*.log files, but
can't post them publicly in this case. If there's any other summaries
the TypeScript team would be curious about I can report them.
## fs.statSync Misses
Within our monorepo, the fs.statSync misses were mostly searches for
alternative file extensions of module imports.
- For node_modules imports, a lot of .ts/.tsx lookups failed until the
.d.ts file was found.
- Within projects with a lot of JSX files, .ts files were looked for
before finding the .tsx version.
- In the medium scale project mentioned above, a total of 38,515
non-existent files were queried during createProgram.
