-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Labels
Comments
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
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
See #2498 in which NTI gives a type error saying basically
Expected T but found T
. Removing the call toUniqueNameGenerator#getOriginalName
inJSType#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.
The text was updated successfully, but these errors were encountered: