* WIP on making the JSX text node not include whitespace
* Scans to the last newline for JSX correctly
* Handle JSX closing element wrapping
* Offload all jsx text indentation handling to indentMultilineCommentOrJsxText
* Switch from find node -> find inde in formatting
Co-authored-by: Wesley Wigham <wwigham@gmail.com>
* Conditionally elide a parameter from contextual type signature calculation
* Slightly different approach to forbid inference to specific expressions
* Handle nested literals and mapped types correctly
* Delete unused cache
* Rename ContextFlags.BaseConstraint and related usage
* Add tests from my PR
* Update ContextFlags comment
Co-Authored-By: Wesley Wigham <wwigham@gmail.com>
* Update comments and fourslash triple slash refs
Co-authored-by: Wesley Wigham <wwigham@gmail.com>
* Allow 'find references' to work on most declaration keywords
* Add support for rename
* Add more keywords, move logic out of checker and into services
* Add additional type and expression keywords
* Handle when files get checked in different orders
* Fix interface extends clause
* Fix import= something type only from a module
* Revert apparently unnecessary addition
* Revert "Revert apparently unnecessary addition"
This reverts commit 7444b0b72e.
* Disallow `import = a.b.c` on anything with type-only imports
* Safety first
* Add test for TS Server single-file open
* Add big comment
* Extract error reporting function for import aliases
* Delete blank line
* Un-export, comment, and colocate some utils
* Combine 3 type-only marking function calls into one
* Add more export default tests
* Class fields w/esnext+[[Define]]:no shadow error
With useDefineForClassFields: true and ESNext target, initializer
expressions for property declarations are evaluated in the scope of
the class body and are permitted to reference parameters or local
variables of the constructor. This is different from classic
Typescript behaviour, with useDefineForClassFields: false. There,
initialisers of property declarations are evaluated in the scope of
the constructor body.
Note that when class fields are accepted in the ECMAScript
standard, the target will become that year's ES20xx
* add negative test case
* Add explanatory comment
Previously subtypes of Error extended Error, but the matching subtypes
of ErrorConstructor did not extend ErrorConstructor. The members in
es5.d.ts are identical, so there's no need except for allowing interface
merging into ErrorConstructor to affect subtypes as well.
Previously the jsdoc index signature syntax was incorrectly treated the
same as Object:
```js
/** @typedef {Object} AllowsNesting
* @property ... */
/** @typedef {Object.<string,string>} IncorrectlyAllowsNesting */
```
Fixes#34911
* Add constructor functions to aliasable expressions
Fixes#35228, at least the crash. There are still a couple of errors
that are probably incorrect.
Note that isJSConstructor relies on parent pointers and the ability to
merge symbols, so I had to move isAliasSymbolDeclaration (back?) to the
checker.
* add simple test case
* remove errors in test
* fix bad merge
Handle private identifiers little better by creating token for private identifier when its just #
Report same error as invalid character but from language service we can now provide completions for this.#
Fixes#36367, #36250
* Fix getExpandoSymbol for already-expando symbols
getExpandoSymbol is intended to get the symbol of the expando in a
declaration like
```js
var C = class {
}
```
However, when this occurs in a `module.exports` assignment, alias
resolution already jumps to the exported symbol -- in this case the
expando symbol:
``js
// @filename: first.js
module.exports = class {
}
// @filename: other.js
/* @type {import("./first")} */
var C
```
`getExpandoSymbol` is then called on `class { }` instead of
`module.exports = class { }`.
Previously, `getExpandoSymbol` would incorrectly treat `class { }` the
same as the export assignment and get the expando ... from the expando
itself. This resulted in merging the expando with itself, which causes
bogus errors and could cause other problems.
Now `getExpandoSymbol` checks that the expando "initializer" is
different from the declaration.
* Better check for getExpandoSymbol of expando
Check the declaration directly instead of the initialiser.
* Allow `infer` type variables to have constraints infered and allow the breakdown of substitutes in simplifiable source inferences
* Still skip conditional inference when `extends infer Q` so such a pattern still acts as a constraint size breaker
* WIP
* Test no longer crashes, but emit trampoline is incomplete and skips pipeline phases
* Fix lints, use non-generator trampoline in emit (still skips pipeline)
* Final version with emitBinaryExprssion work stack that is only used if possible
* Fix lints
* retarget to es2015 for testing
* Use bespoke state machine trampolines in binder and checker
* Remove now extraneous code in parser
* Adjust fixupParentReferences to use a depth first preorder traversal rather than breadth first
* Reintroduce incremental fast bail in fixupParentReferences
* Revert target to es5
* PR feedback
* Small edit for devops rebuild with updated definition
* Fix comment nits, add internally extraneous check back into transformer
* ESNext+[[Define]]: reference to param props illegal
When target: "esnext" and useDefineForClassFields: true, property
declaration initialisers should not be able to reference parameter
properties; class fields are initialised before the constructor runs,
but parameter properties are not:
```ts
class C {
foo = this.bar
constructor(public bar: string) { }
}
```
emits code that looks like this:
```js
class C {
bar
foo = this.bar
constructor(bar) {
this.bar = bar
}
}
new C('x').foo.length // crashes; foo is undefined
```
This PR adds an error on foo's declaration with ESNext+[[Define]].
* improve test
* Emit statements before super
When statements come before super, Typescript's emit is incorrect,
whether there is an error or not. This change preserves statements that
come before super whether there is an error or not.
Here is the case with no errors:
```ts
class Test extends Array {
p: number
constructor() {
console.log("p is initialised in the constructor below super()")
super()
this.p = 1
}
}
```
Notice that `p` is manually initialised in the constructor after
`super()` instead of at the property declaration.
* Update baselines
Parameter properties in the error case now move below the super call.
This is an improvement because it means the code is more likely to execute
correctly.
* remove outdated comments
