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

[NTI] Disambiguate typevars when messages are otherwise nonsense #2499

Closed
shicks opened this issue May 16, 2017 · 0 comments
Closed

[NTI] Disambiguate typevars when messages are otherwise nonsense #2499

shicks opened this issue May 16, 2017 · 0 comments
Assignees
Labels

Comments

@shicks
Copy link
Member

shicks commented May 16, 2017

See #2498 in which NTI gives a type error saying basically Expected T but found T. Removing the call to UniqueNameGenerator#getOriginalName in JSType#toString makes this clearer: Expected T#1 but found T#2. In most cases, the disambiguation hurts readability, so it's probably correct to remove them in most cases, but on some occasions it makes the error extremely baffling.

Ideally we could detect when the error looks like nonsense and re-format it with disambiguation added. In practice, maybe it's not so bad to have it on all the time? In particular, I believe Java's error messages already do this.

@shicks shicks added the NTI label May 16, 2017
blickly pushed a commit that referenced this issue May 25, 2017
This addresses two problems at once:
1. Issue #2499 where type variables are ambiguated, making warnings difficult to understand
2. Migrating `TypedCodeGenerator` to NTI requires printing types in a "for annotations" mode

Rather than add various booleans, the context object allows plumbing any configuration all the way through the recursive stringify operation, and is extensible if further configuration is needed later.  Moreover, context instances may be passed to multiple stringify operations (i.e. to ensure typevars are printed consistently throughout an entire message).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156936000
@brad4d brad4d closed this as completed in 715c0c1 Jun 29, 2017
Yannic pushed a commit to Yannic/com_google_closure_compiler that referenced this issue Jul 6, 2017
This addresses two problems at once:
1. Issue google#2499 where type variables are ambiguated, making warnings difficult to understand
2. Migrating `TypedCodeGenerator` to NTI requires printing types in a "for annotations" mode

Rather than add various booleans, the context object allows plumbing any configuration all the way through the recursive stringify operation, and is extensible if further configuration is needed later.  Moreover, context instances may be passed to multiple stringify operations (i.e. to ensure typevars are printed consistently throughout an entire message).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156936000
Yannic pushed a commit to Yannic/com_google_closure_compiler that referenced this issue Jul 6, 2017
A unique numeric suffix is appended only when two different typevars with the same name are found in a message.

Fixes google#2499

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160473908
Yannic pushed a commit to Yannic/com_google_closure_compiler that referenced this issue Jul 6, 2017
A unique numeric suffix is appended only when two different typevars with the same name are found in a message.

Fixes google#2499

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160473908
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants