-
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
Avoid diagnostic message forcing crashing the compiler #19113
Conversation
Because HideNonSensicalMessages looks at hasErrors, we need to narrow the faking to just the isNonSensical call
_errorCount += 1 | ||
dia.msg.isNonSensical | ||
finally _errorCount -= 1 // decrease rather than reset the value so we only ever decrease by 1 | ||
else dia.msg.isNonSensical) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we simply test hasErrors
first? Then the isNonSensical
test is assured to run with errorCount > 0
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, but I had to make another change too.
We can switch to a more straightforward hasErrors check in isHidden, but then we need to bump the errorCount before calling doReport, as doReport will then, necessarily, force the message. For reference, the way I test this manually is by: 1. In ignoredConvertibleImplicits, changing back to `viewExists(imp, fail.expectedType)` 2. In adapt1, removing the `dummyTreeOfType.unapply(tree).isEmpty` guard 3. Compiling tests/neg/i18650.scala Also, while I'm here, instruct on the presence of -Yno-enrich-error-messages, like we do for -Yno-decode-stacktraces.
Using issue scala#18650 as the reference (but issue scala#18999 is another option) building on the fix in PR scala#18719 (refined in PR scala#18727) as well as the fix in PR scala#18760, I'm trying to make a more root change here by making sure that message forcing only occurs with `hasErrors`/`errorsReported` is true, so as to avoid assertion errors crashing the compiler. (cherry picked from commit 10f2c10)
Using issue scala#18650 as the reference (but issue scala#18999 is another option) building on the fix in PR scala#18719 (refined in PR scala#18727) as well as the fix in PR scala#18760, I'm trying to make a more root change here by making sure that message forcing only occurs with `hasErrors`/`errorsReported` is true, so as to avoid assertion errors crashing the compiler. (cherry picked from commit 10f2c10)
Using issue #18650 as the reference (but issue #18999 is another option) building on the fix in PR #18719 (refined in PR #18727) as well as the fix in PR #18760, I'm trying to make a more root change here by making sure that message forcing only occurs with
hasErrors
/errorsReported
is true, so as to avoid assertion errors crashing the compiler.