* Bind alias ThisProperty assignment declarations
This is a quick prototype that does the wrong thing at the wrong time
with the wrong technique.
* Preliminary checker handling for aliases
Duplicative and untested, but I think I updated all the places that need
updating.
* new is error; old one should not have been removed
* I don't even know what's happening with this test
* cleanup and testing in the checker
* binder: use lookupSymbolForNameWorker instead of mutable
This should have about the same behaviour and is much easier to
understand.
Also refactor common code a bit.
* Shorter name of lookupSymbolForName
Once upon a time there was a parent/worker function, but now it's just a
single function again. No need for the -Worker suffix.
* remove oodate comment
* fix switch-case-break lint
* Refactor and move functions
* Rename and improve type of getContextualTypeForAssignmentDeclaration
* Fix this parameter emit for JSDocFunction types
Previously, parameters with names that were not `new` were treated like
rest parameters. This is incorrect: parameters with the name `this`
should emit a `this` parameter.
Fixes#38550
* ❤️ quote style
Previously, getObjectTypeInstantiation had special-case code to look up
type parameters for `@param` as if they were in the parameter location.
This should occur in the main lookup loop of `getOuterTypeParameters`,
however. The current code only runs once, which is not sufficient, and
it also jumps to the parameter for any type contained in a `@param`,
which skips type parameters that occur in the tag itself.
* Type `this` in more constructor functions
Previously, `this: this` in constructor functions only when there was
an explicit `@constructor` tag on the function. Now, `this: this` for
any function that's known to be a constructor function.
This improves completions inside constructor functions; also note that
previously the compiler *did* type `this: this` inside methods of constructor
functions, so this fix makes us more consistent. This is reflected in
the large number of baselines that improve.
The fix is a simple switch to `isJSConstructor`, which is the standard
way to detect constructor functions. I'm not sure why the original PR
didn't use this method.
I remember discussing this limitation in the original bug, #25979, and
I guess I decided that it made sense. But I was heavily primed by the bug's
framing of the problem in terms of `noImplicitThis`, which *should*
require an explicit `@constructor` tag.
With better typing comes better detection of `@readonly` assignment; I
had to fix the readonly detection code to use `isJSConstructor` as well.
* Remove `Add @class tag` fix for noImplicitThis.
The new rules mean that it never applies. It's possible that it should
apply to functions like
```js
function f() {
this.init()
}
```
In which `init` is never defined, but I think this program is incomplete
enough that not offering the fix is fine.
* Fix precedence of `@this`
Previously, both `@class` and `@this` in a jsdoc would cause the `@this`
annotation to be ignored. This became a worse problem with this PR,
because `this` is correctly typed even without the annotation.
This commit makes sure that `@this` is checked first and used if
present.
* Parse *= separately in types
Previously, when the scanner produced `*=` as a single token, the type
parser ran special-case code to produce an "optional all type", which
only makes sense when the `=` really should be attached to the `*`. This
is often not the case.
The correct solution, which I missed when I first wrote this code, is to
have the scanner go back and produce a separate `=` token, which is what
this PR does.
* add test from #38551
* we ❤️ semicolons
Previously, property assignments with `void 0` initialisers were treated
like any other values. But this causes us to choke when checking our own
commonjs emit. This is something that happens by mistake a fair amount,
so this PR goes back to treating these assignments as normal
assignments.
This should allow us to check our own emit in loose cases without
harming other code bases, since `void 0` is rarely written by hand.
Note that other errors still happen: noImplicitAny forbids
accessing undeclared properties on object literals, and strictNullChecks
forbids assigning `undefined` to properties with a different type.
However, this change is enough to unblock compilation with
`strictNullChecks: false`.
* Initial implementation of variadic tuple types
* Accept new baselines
* Handle variadic elements in tuple type inference
* Special case inference between tuples with matching structure
* Restore check that rest element is last element
* Handle variadic tuples in relationship checking
* Accept new baselines
* Infer readonly constraints when inferring from readonly tuples
* Fix lint issues
* T assignable to readonly [...T] and [...T] assignable to T
* Consistent tuple normalization
* Create variadic tuple types from array literal expressions
* Accept new baselines
* Array literals have tuple types when contextual type is readonly
* Accept new baselines
* Optional elements before required elements become required elements
* Update logic for rest parameters and spread arguments
* Revert special case of contextual readonly array type
* Accept new baselines
* Fix lint issue
* Switch entirely to createTupleType based on element flags
* Don't infer readonly tuple types when inferring to variadic elements
* Handle mapped types applied to generic tuple types
* Handle constraint of indexed access type with generic tuple type
* Accept new baselines
* Address CR feedback
* Simplify indexed access types involving generic tuple types
* Propagate checkMode into getSpreadArgumentType
* Guard against missing globalArrayType
* Inference to [...T, ...U] based on implied arity of T
* Accept new baselines
* Add tests
* Emit .d.ts from tests
* Address CR feedback
Outside of JSDoc comments, postfix-? is parsed at lower precedence than
the `?` of conditional types, and a postfix-? inside a tuple type
results in the type being marked optional.
This PR changes JSDoc parsing to behave the same way, which means that
1. Conditional types are allowed in JSDoc. Fixes#37166.
2. Tuple types' postfix-? syntax is interpreted correctly in JSDoc.
Fixes#38747.
The breaking change is that a postfix-? type followed by another postfix type,
like `[]` or `!`, is parsed as a conditional type. [Postfix-? is not
common](https://github.com/microsoft/TypeScript/issues/37166#issuecomment-612274456),
so this is an acceptable breaking change.
A postfix-? type `T?` is still parsed everywhere else and treated as `T | null`.
Neither `x[0]` nor `x[(0)]` should be dynamic names. Previously, the
latter was because `isDynamicName` didn't skip parentheses.
Since the binder treats dynamic names in property assignments as
assignment declarations, this incorrectly tried to create a binding for
expressions like `x[(0)] = 1`.
This caused an assert because `x[(0)]` would not take the dynamic name
code path during binding (`hasDynamicName` returned false), but the
normal code path for static names.
* fix(38750): create unique names for keywords and re-export them with original names
* Serialize (noncontextual) keyword named namespace members with export declarations in both declaration emitters
* Add exhaustive keyword emit test for js declaration emitter and fix it up
Co-authored-by: Alexander T <alexander.tarasyuk@outlook.com>
This completes the work that started in PR #33069, and fixes#32835.
There are probably two additional related changes that are needed to
make this more complete:
* Fix the code that composes the error message (see the first two
`FIXME`s in `callWithSpread3.ts`).
* Fix the code that checks the argument types (second two `FIXME`s).
* There is also an error in `genericRestParameters1.ts` which changed
but should not be an error in the first place. Added a `FIXME` there
too. (Probably will work if the previous iterm is done.)
In addition, `getEffectiveCallArguments` munges the arguments in case of
a spread in the last argument which might be better to avoid. (I think
that there are cases where it wouldn't work anyway, such as a spread of
an array followed by a spread of an empty array.)
* fix: range of ts2657 (jsx expr must have parent) and remove 2695 (LHS expr of comma has no side effects)
* feat: add code fix for 2657
* fix: resolve review
* chore: hoist a var
* chore: add test for skipTrivia
* fix: rebase error
* Update src/compiler/diagnosticMessages.json
Co-authored-by: Andrew Branch <andrewbranch@users.noreply.github.com>
* Update src/services/codefixes/wrapJsxInFragment.ts
Co-authored-by: Andrew Branch <andrewbranch@users.noreply.github.com>
Co-authored-by: Andrew Branch <andrew@wheream.io>
Co-authored-by: Andrew Branch <andrewbranch@users.noreply.github.com>
