* Avoid circular reference in this-property assignments
To do this, don't check this-property assigments that have the
this-property of the lhs appearing somewhere on the rhs:
```js
class C {
m() {
this.x = 12
this.x = this.x + this.y
}
}
```
I tried suppressing the circularity error, but because we cache the
first type discovered for a property, this still results in an implicit
any for `x` in the previous example. It just doesn't have an error.
Fixes#35099
* Add test case + rename function
* Use isMatchingReference
Get the `declaration` container just once instead of in three places.
(Minor change: one place used to start looking from
`declaration.parent`, but that shouldn't make any difference.) Also,
don't pass it to the helper functions since they're local anyway.
This only applies in JS, where `@template` tags can apply to
initialisers of variable declarations:
```js
/**
* @template T
* @returns {(b: T) => T}
*/
const seq = a => b => b
```
Fixes#36201
* Consolidated extra property check with intersections
* Fix comment
* Add tests
* Properly propagate intersectionState
* Route property check through recursive type tracking logic
* Accept new baselines
* Skip check when apparent type of source is never
* Accept new baselines
* Only check when apparent type of source is a structured type
* Fix serialisation of static class members in JS
Previously static class members would be treated the same way as expando
namespace assignments to a class:
```ts
class C {
static get x() { return 1 }
}
C.y = 12
```
This PR adds a syntactic check to the static/namespace filter that
treats symbols whose valueDeclaration.parent is a class as statics.
Fixes#37289
* fix messed-up indent
* Extract function
* Fix crash for private identifier in expando assignments
It does this by disallowing private identifiers from expando assignments
entirely. I haven't thought of a scenario where they make sense, but I
haven't thought about it exhaustively either.
Fixes#37356
* Update baselines
I think the new error is probably better. It's certainly different!
* Elaborate on reasons for 'never' intersections
* Accept new API baselines
* Accept new baselines
* Add tests
* Accept new baselines
* Address CR feedback
Previously, spreading an optional any gave a bogus error when the name
conflicted with earlier properties in the object literal. Now the code
checks any types for optionality before issuing the error.
Fixes#37740
