Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bind non-expando property assignments at top-level #26908

Merged
merged 2 commits into from
Sep 5, 2018

Conversation

sandersn
Copy link
Member

@sandersn sandersn commented Sep 5, 2018

Previously, only property assignments with expando initialisers were bound in top-level statements. Now, all property assignments are bound.

This requires a matching change in the checker to make sure that these assignments remain context sensitive if their valueDeclaration is a 'real' declaration (ie a non assignment-declaration).

Note that this accords with the recent change of SymbolFlags.JSContainer → SymbolFlags.Assignment such that all assignment declarations are marked instead of just ones that could be a container later.

Fixes #26875

Previously, only property assignments with expando initialisers were
bound in top-level statements. Now, all property assignments are bound.

This requires a matching change in the checker to make sure that these
assignments remain context sensitive if their valueDeclaration is a
'real' declaration (ie a non assignment-declaration).
@@ -1,12 +1,12 @@
=== tests/cases/conformance/salsa/a.js ===
var variable = {};
>variable : { a: number; }
>variable : typeof variable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to consider not using typeof on the printout of expando types if they don't contain call/construct signatures? Just a thought.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this is a JS scenario, I think that the "value name as type name" pattern is actually more understandable than a structural type -- for authors, though not for us. chrome-devtools-frontend, for example: would they rather see typeof Common or { Ns1: { ... }, Ns2: { ... } }?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think it depends on use. If it's being used like a namespace, then typeof is fine, but if it's being used like an expanding object literal, then the final type would probably be desirable. Seems kinda heuristic to me. Would be nice if we could display the detailed type in the editor on request, though.

==== tests/cases/conformance/salsa/bug24658.js (1 errors) ====
import { hurk } from './mod1'
~~~~
!!! error TS2440: Import declaration conflicts with local declaration of 'hurk'.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Should we make this merge work in JS, rather than making it an error? We already allow import merges when the kinds don't conflict, and JS merges are like a merge-when-the-kinds-to-conflict.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can merge with an import? In the original discussion for this bug #24658, Mohamed and I just assumed that it was an error. Can you point me to the code/tests for import merges?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #26912 to track merging imports and assignment declarations

Copy link
Member

@weswigham weswigham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm OK with this as-is, just some comments for consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants