* Increase timeout for ensuring projects for open files
* Condense the project/file printing in the log (given now we have project printed anytime its structure changes)
* Use objects instead of closures for type mappers
* Flatten combined type mappers
* Single point of creation for type mappers
* More optimizations
* Fix lint error
* Fewer symbol instantiations / discard type mapper after instantiation
* More optimizations
* Simplify mapper layout and cache in composite mappers
* Removing cache as it doesn't seem to matter much
* Get rid of identityMapper
* Implement constructor type guard
* Fix code review issues for constructor type guard.
- Do not limit constructor expression to only identifiers
- Fix `assumeTrue` and operator no-narrow check
- Use better way to check that identifier type is a function
- Loosen restriction on what expr is left of ".constructor"
- Update typeGuardConstructorClassAndNumber test to include else cases
* Fix grammar & spacing in `narrowTypeByConstructor`
* fix bad merge
* switch (back?) to crlf
* update baselines
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
Using a constructor function like this can help node better optimize
object allocation. This improves memory usage when compiling
`src/compiler` from **277M** to **270M**, a nice ~3% win.
As stated in 26417, `host` is only ever written to and never read from. `createProgramHost` is the only place I could find that provides a member for `ProgramHost`'s `onCachedDirectoryStructureHostCreate`, so that's removed as well.
As per the linked issue, although TypeScript already has checking in place that tries to prevent users from extending classes before their declaration, it's still possible to accidentally work around the checker. This adds a block to `__extends` that throws a `TypeError` if the base class `b` isn't a function.
My _hope_ is that this will not have a negative performance impact on community performance-critical applications, as they would likely already prefer newer browser/Node versions and output ES2015+ code. If there is something you can think of that I should do to verify that hope, I'd love to know!
For reference, runtime errors in Node 12.0.0 (Chrome exhibits the same messages):
```js
class X extends null { }
// undefined
class Y extends undefined { }
// TypeError: Class extends value undefined is not a constructor or null
class Z extends 0 { }
// TypeError: Class extends value 0 is not a constructor or null
```
`Class extends value {0} is not a constructor or null` matches the Node.js behavior:
* [Message template](https://github.com/nodejs/node/blob/2bdeb88c27b4d8de3a8f6b7a438cf0bcb88fa927/deps/v8/src/common/message-template.h) for `ExtendsValueNotConstructor`
* [Error thrown with that message](https://github.com/nodejs/node/blob/6ca81ad72a3c6fdf16c683335be748f22aaa9a0d/deps/v8/src/runtime/runtime-classes.cc#L617) when `!super_class->IsConstructor()`
Runtime errors in Firefox 72.0.1:
```js
class X extends null { }
// undefined
class Y extends undefined { }
// TypeError: class heritage undefined is not an object or null
class Z extends 0 { }
// TypeError: class heritage 0 is not an object or null
```
* Allow passing watch to the change as parameter
* Reset hasChangedAutomaticTypeDirectiveNames once new program is created
Also dont invoke afterProgramCreate if the program is not new
Resolves issue #28031 by overriding default value of
`useNonAdjustedStartPosition` option to replaceNode. Test case included
that confirms intended behaviour.
* Added @ts-expect-error to @ts-ignore directives
Similar to `// @ts-ignore`, but will itself cause a new error diagnostic if it does not cause an existing diagnostic to be ignored.
Technical summary:
1. The scanner will now keep track of `CommentDirective`s it comes across: both `@ts-expect-error` and `@ts-ignore`
2. During type checking, the program will turn those directives into a map keying them by line number
3. For each diagnostic, if it's preceded by a directive, that directive is marked as "used"
4. All `@ts-expect-error` directives not marked as used generate a new diagnostic error
* Renamed to getDiagnosticsWithPrecedingDirectives per suggestion
* Added JSDoc comment I thought I did already
Co-authored-by: Orta <orta.therox+github@gmail.com>
Use `emit()` for writing `questionDotToken`, leading to properly calling
the emit hooks (which `emitTokenWithComment` doesn't) and printing the
comments. This fixes#35372 by calling its hooks to set the `.__pos`
and `.__end` fields.
Also, remove `getDotOrQuestionDotToken` which was used only here --
mainly because it seems likely to encourage misusing the
`questionDotToken` again.
Also, fix a bunch of `visitor` -> `tokenVisiton` calls in
`visitorPublic.ts`.
* More precise property-overwritten-by-spread errors
Trying to do this check in getSpreadType just doesn't have enough
information, so I moved it to checkObjectLiteral, which is a better
place for issuing errors anyway.
Unfortunately, the approach is kind of expensive in that it
1. creates a new map for each property and
2. iterates over all properties of the spread type, even if it's a
union.
I have some ideas to improve (1) that might work out. I'm not sure how
bad (2) is since we're going to iterate over all properties of all
constituents of a union.
Fixes#36779
* another test and rename
* Reinterpret a type parameter constrained to any as an upper bound constraint
* Use real constraqint in alias in test
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Optionally stop looking for the default configured project at
node_modules
* Make stopping at node_modules non-optional
* Generalize and simplify the change - node_modules files don't have default configured projects
Sheetal NandiandGitHub
csigs
Anders HejlsbergandGitHub
Arpad BorsosandGitHub
Jack WilliamsandGitHub
Iku IwasaandGitHub
Josh GoldbergandGitHub
Andrew BranchandGitHub
Alexander TandGitHub
Jonathan ShareandGitHub
Ben LichtmanandGitHub
Ben Lichtman
Eli Barzilay
Ryan CavanaughandGitHub
Wesley WighamandGitHub
Andrew CaseyandGitHub