* 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`.
Sheetal Nandi
Anders Hejlsberg
Austin Cummings
csigs
csigs
Arpad Borsos
Wenlu Wang
Jack Williams
Iku Iwasa
Ethan Resnick
Josh Goldberg
Andrew Branch
Alexander T
Jonathan Share
Ben Lichtman
Ben Lichtman
Nathan Shively-Sanders
Orta
Eli Barzilay
Ryan Cavanaugh
Wesley Wigham