-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Error messages are vague when types have the same name #1419
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
Comments
true 😃 |
It reminds me of this Steve Yegge post from way back.
You might note the irony of the section that appears in. 😄 |
Did anyone ever end up working on this? I took a look at it this morning and it doesn't seem too bad. I'll send out a PR when I get a chance to finish it up & test. |
@chrisbubernak, I worked on this a few weeks back, was a pretty minor change but it ended up breaking some other things (when I looked at the baselines, I believe it was something with the require paths now gone from the baseline), and I never had the time to actually look at it more. :( |
@DanielRosenwasser /@chrisbubernak, I ran into this gem today using 1.4:
I mean |
That error looks like a bug. Do you have a repro? Or is it that there are two different |
@RyanCavanaugh, there's only one |
We're almost there; #1798 is probably the next pain-point to tackle. |
Consider the following:
The subtlety is that the user meant to declare
ts.Node
as the type ofn
.Here you'll get the error on
n
within theforEachChild
call, with the messagewhich is unhelpful because it makes the user feel like they've completely lost their mind.
We should use a qualified name in such cases.
The text was updated successfully, but these errors were encountered: