-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix parsing crash for update in later phases #23390
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
base: main
Are you sure you want to change the base?
Conversation
@odersky I'm not quite sure I understand why the Feature.ccEnabled check fails in subsequent phases inside |
The ccEnabled test asks whether it's enabled for the current compilationUnit. Is that set correctly for rendering? That's where I would look. |
In fact, no, the compilation unit is " |
@@ -3291,7 +3291,7 @@ object Parsers { | |||
case nme.infix => Mod.Infix() | |||
case nme.tracked => Mod.Tracked() | |||
case nme.erased if in.erasedEnabled => Mod.Erased() | |||
case nme.update if Feature.ccEnabled => Mod.Update() |
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.
Let's tackle the problem at the root, here we just paper over it.
We need to intervene in Feature.scala
/** Is captureChecking enabled for this compilation unit? */
def ccEnabled(using Context) =
enabledBySetting(captureChecking)
|| ctx.compilationUnit.needsCaptureChecking
Here, the compilationUnit is wrong for highlighting What we can do though, is that if the compilation unit is "<highlighting>
"
we move outwards (using ctx.outer) until we find another compilation unit or the context is NoContext. Then use that other compilation unit for the test. We can encapsulate that behavior in a new def originalCompilationUnit
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.
Addressed
Fixes #23389