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

Rationalize type/value conflict handling. #1126

Merged
merged 3 commits into from
Dec 6, 2019
Merged

Rationalize type/value conflict handling. #1126

merged 3 commits into from
Dec 6, 2019

Conversation

mprobst
Copy link
Contributor

@mprobst mprobst commented Dec 2, 2019

While separate in TypeScript, in Closure Compiler the type and value
namespaces are merged. This means tsickle must take care not to emit
duplicate symbols for type/value conflicts, and chooses the value over
the type.

That in turn means tsickle cannot generally emit references to types
that have a type value conflict, i.e. symbols in the TS API that have
both the Type and the Value SymbolFlag set.

However we special case two situations: (1) builtin symbols such as
Array, where we rely on the Closure definition and thus assume the
type/value conflict is handled on that level; and (2) symbols generated
by Clutz, which are also defined in Closure land so the conflict is not
a problem.

However previously we had two different code paths both handling parts
of this, one for type references in @implements, one for all other
type references. Both paths only handled either (1) or (2). This change
rationalizes the situation, handling (1) and (2) in both code paths.

Fixes #1116.

While separate in TypeScript, in Closure Compiler the type and value
namespaces are merged. This means tsickle must take care not to emit
duplicate symbols for type/value conflicts, and chooses the value over
the type.

That in turn means tsickle cannot generally emit references to types
that have a type value conflict, i.e. symbols in the TS API that have
both the Type and the Value SymbolFlag set.

However we special case two situations: (1) builtin symbols such as
`Array`, where we rely on the Closure definition and thus assume the
type/value conflict is handled on that level; and (2) symbols generated
by Clutz, which are also defined in Closure land so the conflict is not
a problem.

However previously we had two different code paths both handling parts
of this, one for type references in `@implements`, one for all other
type references. Both paths only handled either (1) or (2). This change
rationalizes the situation, handling (1) and (2) in both code paths.
While `implements Boolean` might be not particularly sensical, this
asserts that we call the right functionality for type/value inheritance
conflicts.
These are included in the TypeScript standard library, but not in the
Closure Compiler externs.
src/type_translator.ts Show resolved Hide resolved
src/closure_externs.js Show resolved Hide resolved
@blickly
Copy link
Contributor

blickly commented Dec 4, 2019

LGTM

@mprobst mprobst merged commit b8ec19f into master Dec 6, 2019
@mprobst mprobst deleted the type-value branch December 9, 2019 09:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rationalize handling of type/value conflicts
4 participants