Type-argument defaulting is handled elsewhere in the compiler.
This is a small drive-by improvement, so I didn't change the handling of
'array' or 'promise'; they still manually create `any[]` and
`Promise<any>`, respectively.
* Remove redundant checker functions, use patterns more friendly to modules
* Also use a helper for localizedDiagnosticMessages
* Move types into same file as consts
* Accept slightly changed api baseline
* Whitespace!
It's also defined in `corePublic.ts` - there's no errors because they're (almost) identical and merge (creating a redundant overload for `push`). Ironically, while this definition was internal, the other is public (and more complete).
When using `{import('./b').FOO}` which is defined as a string literal,
`valueType` doesn't have a `symbol`. Leave it for the fallback value
for now.
This was exposed in 8223c0752.
Fixes#34869.
* When calculating spreads, merge empty object into nonempty object to produce partial object to reduce complexity
* Actually accept remainder of baselines
* Limit simplification to single prop or partial types
* Normalize type references before relating them in isRelatedTo
* Add comments
* Accept new baselines
* Add regression tests
* Accept new baselines
* Use aliases when available in error reporting
* Accept new baselines
* Emit defineProperty calls before param prop assignments
Note that I restricted this to --useDefineForClassFields is true.
Nothing changes when it's off. I think this is the correct fix for a
patch release.
However, in principal there's nothing wrong with moving parameter
property initialisation after property declaration initialisation. It
would be Extremely Bad and Wrong to rely on this working:
```ts
class C {
p = this.q // what is q?
constructor(public q: number) { }
}
```
But today it does, and probably somebody relies on it without knowing.
* Put parameter property initialiser into defineProperty's value
* Combine ES5/ESNext into one test
* useDefineForClassFields skips emit of ambient properties
Previously:
```ts
class C {
declare p
}
```
would incorrectly emit
```js
class C {
constructor() {
Object.defineProperty(this, "p", {
enumerable: true,
configurable: true,
writable: true,
value: void 0
});
}
}
```
when useDefineForClassFields was turned on (for targets <ESNext).
* Fix bug for ESNext as well
This moves the check earlier in the pipeline.
* update baselines
* Fix up quotation marks in error messages in JavaScript files.
* Accepted baselines.
* Typescript -> TypeScript
* Accepted baselines.
* Migrate syntactic diagnostics tests to baselining tests.
* Accepted baselines.
* Update diagnosticMessages.json
* Removed markers.
* Add ability to baseline both semantic and syntactic diagnostics.
* Fix up broken diagnostics when using a server LS.
* Accepted baselines.
* Lints.
* Fake up sourcefile objects in the tsserver session client instead.
* Fewer allocations.
Also, drop the other cases where they were ignored, since they're
forbidden in enums, and the others are fine wrt the comment that was
there.
Fixes#34892
* Add inference priority level for conditional types in contravariant positions
* Accept new API baselines
* Add regression tests
* Accept new baselines
* Add preceding semicolon on await insertion when parentheses are included
* Just start with precedingToken
* Fix semicolon formatter regression
* Delete test with debatable expected behavior
* Lint after control flow changes
