skipping narrowing if the old algorithm produces a type to which the
assigned type is not assignable.
This also means we'll no longer narrow for erroneous assignments where
the assigned type is not assignable to the declared type. This is the
reason for the numericLiteralTypes3 baseline change.
Fixes#26405.
Previously, they were mistakenly treated as private because of a check
that required all super property accesses (like `super.x()`) to be
references to a MethodDeclaration or MethodSignature. This change also
allows PrototypeProperty special assignment kinds.
* Allow special property assignments in TS
But only for functions and constant variable declarations initialised with
functions.
This specifically excludes class declarations and class expressions,
which differs from Javascript. That's because Typescript supports
`static` properties, which are equivalent to property assignments to a
class.
* Improve contextual typing predicate
Don't think it's right yet, but probably closer?
* More fixes.
The code is still fantastically ugly, but everything works the way it
should.
Also update baselines, even where it is ill-advised.
* Cleanup
* Remove extra whitespace
* Some kind of fix to isAnyDeclarationName
It's not done yet.
Specifically, in TS:
Special property assignments are supposed to be declaration sites (but not all
top-level assignments), and I think I
got them to be. (But not sure).
In JS:
Special property assignments are supposed to be declaration sites (but not all
top-level assignments), and I'm pretty sure ALL top-level assignments
have been declaration sites for some time. This is incorrect, and
probably means the predicate needs to be the same for both dialects.
* Add fourslash and improve isAnyDeclarationName
Now JS behaves the same as TS.
* Cleanup from PR comments
* This-property w/empty object init: use type annotation
* JS initializer type doesn't apply to this-property assignments
* Move getJSExpandoType into getWidenedType* functions
Plus some cleanup.
* Improved style from PR comments
* Parameters are not expando
* Narrow literal element accesses
This means that, for example, the tuple `[number, string?]` allows its
second element to be narrowed with element access:
```ts
export function f(pair: [number, string?]): string {
return pair[1] ? pair[1] : 'nope';
}
```
* Update baselines
* Cleanup
* More cleanup
* Test dashes in property names
* More cleanup
* Delete undead code
Sheetal Nandi
Ryan CavanaughandGitHub
David SherretandDavid Sherret
AndyandGitHub
Ron BucktonandGitHub
Anders HejlsbergandGitHub
Matt McCutchen
Wesley WighamandGitHub
TypeScript BotandNathan Shively-Sanders
Tim SchaubandNathan Shively-Sanders
Daniel RosenwasserandGitHub
Daniel Rosenwasser