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

Jump to bottom

do not look for similar identifiers when typer should remain silent #5382

Closed
scabug opened this issue Jan 17, 2012 · 5 comments
Closed

do not look for similar identifiers when typer should remain silent #5382

scabug opened this issue Jan 17, 2012 · 5 comments
Assignees
@paulp

Comments

@scabug
Copy link

scabug commented Jan 17, 2012

typedIdent should not compute the val similar when the error message is never going to be presented to the user

this is a killer in scala-virtualized, since we do a ton of typedIdent("infix_"+someName), only to find out whether that identifier exists -- I had to kill ant quick.bin after 20 minutes (whereas it normally takes about 1:15min)

I didn't see a robust way of detecting whether the reporter is silent or not, apart from context.reportGeneralErrors, but relying only on that condition broke your test cases, so I'm giving up and throwing the hot potato in your direction in hopes of your reflexes' making you catch it
@scabug
Copy link
Author

scabug commented Jan 17, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5382?orig=1
Reporter: @adriaanm

@scabug
Copy link
Author

scabug commented Jan 17, 2012

@adriaanm said:
Hubert, when you merge the new-style error-reporting can you have a look at this?

@scabug
Copy link
Author

scabug commented Jan 17, 2012

@paulp said:
I can eat this potato, dealing better with "silent" is very necessary anyway.

@scabug
Copy link
Author

scabug commented Jan 17, 2012

@hubertp said:
which test exactly was it failing at?
I am atm merging again with trunk, so Paul you can expect a huge pull request soon (enjoy!). I was going to wait for benchmarking to work again but that is taking too long for me and my own testing showed that performance is ok.
It should be possible then to just call 'context.hasErrors' and voila (and inspect what can kind of error occurred if you have such a desire).

@scabug
Copy link
Author

scabug commented Jan 23, 2012

@adriaanm said:
fixed by Paul in 8deade7d868dbd79194621d815ee6eee46f9807d

@scabug scabug closed this as completed Jan 23, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@paulp paulp

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@paulp @scabug