* 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.
* Mark @typedef as a type declaration
This is only important right now for marking uses of deprecated tags due
to the way that deprecated type references are computed. But I'm
surprised it hasn't caused problems elsewhere.
Fixes#39466
* Also mark @callback and @enum
Requires making name lookup in isTypeDeclarationName smarter, but this
is only used by services, so shouldn't be too performance sensitive.
* 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`.
* Split the GH actions CI into multiple stages
* Add the -- for npm
* Improve the CI reports
* Use stylish formatting on CI
* Break TSC instead
* Try add the problem register for TSC only on node 12
* Fix GH Actions syntax maybe
