maxmustermann/TypeScript
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
TypeScript/tests/baselines/reference/assignmentToVoidZero2.symbols

57 lines
2.1 KiB
Plaintext
Raw Normal View History

In JS, assignment to `void 0` isn't a declaration (#39452) 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`.
2020-07-06 23:00:12 +02:00
=== tests/cases/conformance/salsa/assignmentToVoidZero2.js ===
exports.j = 1;
>exports.j : Symbol(j, Decl(assignmentToVoidZero2.js, 0, 0))
>exports : Symbol(j, Decl(assignmentToVoidZero2.js, 0, 0))
>j : Symbol(j, Decl(assignmentToVoidZero2.js, 0, 0))
exports.k = void 0;
>exports : Symbol("tests/cases/conformance/salsa/assignmentToVoidZero2", Decl(assignmentToVoidZero2.js, 0, 0))
var o = {}
>o : Symbol(o, Decl(assignmentToVoidZero2.js, 2, 3), Decl(assignmentToVoidZero2.js, 2, 10))
o.x = 1
>o.x : Symbol(o.x, Decl(assignmentToVoidZero2.js, 2, 10))
>o : Symbol(o, Decl(assignmentToVoidZero2.js, 2, 3), Decl(assignmentToVoidZero2.js, 2, 10))
>x : Symbol(o.x, Decl(assignmentToVoidZero2.js, 2, 10))
o.y = void 0
>o : Symbol(o, Decl(assignmentToVoidZero2.js, 2, 3), Decl(assignmentToVoidZero2.js, 2, 10))
o.x + o.y
>o.x : Symbol(o.x, Decl(assignmentToVoidZero2.js, 2, 10))
>o : Symbol(o, Decl(assignmentToVoidZero2.js, 2, 3), Decl(assignmentToVoidZero2.js, 2, 10))
>x : Symbol(o.x, Decl(assignmentToVoidZero2.js, 2, 10))
>o : Symbol(o, Decl(assignmentToVoidZero2.js, 2, 3), Decl(assignmentToVoidZero2.js, 2, 10))
function C() {
>C : Symbol(C, Decl(assignmentToVoidZero2.js, 5, 9))
this.p = 1
Type `this` in more constructor functions (#39447) * 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.
2020-07-08 17:44:17 +02:00
>this.p : Symbol(C.p, Decl(assignmentToVoidZero2.js, 7, 14))
>this : Symbol(C, Decl(assignmentToVoidZero2.js, 5, 9))
In JS, assignment to `void 0` isn't a declaration (#39452) 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`.
2020-07-06 23:00:12 +02:00
>p : Symbol(C.p, Decl(assignmentToVoidZero2.js, 7, 14))
this.q = void 0
Type `this` in more constructor functions (#39447) * 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.
2020-07-08 17:44:17 +02:00
>this : Symbol(C, Decl(assignmentToVoidZero2.js, 5, 9))
In JS, assignment to `void 0` isn't a declaration (#39452) 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`.
2020-07-06 23:00:12 +02:00
}
var c = new C()
>c : Symbol(c, Decl(assignmentToVoidZero2.js, 11, 3))
>C : Symbol(C, Decl(assignmentToVoidZero2.js, 5, 9))
c.p + c.q
>c.p : Symbol(C.p, Decl(assignmentToVoidZero2.js, 7, 14))
>c : Symbol(c, Decl(assignmentToVoidZero2.js, 11, 3))
>p : Symbol(C.p, Decl(assignmentToVoidZero2.js, 7, 14))
>c : Symbol(c, Decl(assignmentToVoidZero2.js, 11, 3))
=== tests/cases/conformance/salsa/importer.js ===
import { j, k } from './assignmentToVoidZero2'
>j : Symbol(j, Decl(importer.js, 0, 8))
>k : Symbol(k, Decl(importer.js, 0, 11))
j + k
>j : Symbol(j, Decl(importer.js, 0, 8))
>k : Symbol(k, Decl(importer.js, 0, 11))
Reference in a new issue Copy permalink