-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix Crashes when Capture-set Parameters Conflict with Terms #25029
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
|
Perhaps we should also rule out nonsense like |
dd7edc6 to
1edffb0
Compare
When reporting a naming conflict for a PhantomSymbol, we attempt to use its companionClass for a better error message. However, companionClass can return NoSymbol when no companion exists, and accessing .owner on NoSymbol throws NoDenotation.owner assertion error. This fix checks if the companion exists before using it, falling back to the original conflicting symbol otherwise. Fixes scala#25025
1edffb0 to
9689e7d
Compare
noti0na1
left a comment
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.
LGTM
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.
Pull request overview
This PR fixes compiler crashes (NoDenotation.owner and ClassCastException) that occurred when capture-set parameters ([c^]) conflict with term definitions of the same name in Scala's experimental capture checking feature. The fix adds proper error detection and reporting with clear, informative error messages.
Changes:
- Fixed
NoDenotation.ownercrash by using.orElse()whencompanionClassreturnsNoSymbol - Fixed
ClassCastExceptionby adding pattern matching to handle cases where widened type is not aTypeRef - Added proactive conflict detection in
addDummyTermCaptureParamto catch term parameter before capture parameter pattern - Enhanced error messages for capture-set conflicts with proper categorization and explanations
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
tests/neg-custom-args/captures/i25025.scala |
Test cases covering various capture-set parameter conflict scenarios |
tests/neg-custom-args/captures/i25025.check |
Expected error messages with proper error codes (E161) |
compiler/src/dotty/tools/dotc/typer/Namer.scala |
Fixed crash by safely handling NoSymbol from companionClass |
compiler/src/dotty/tools/dotc/typer/Typer.scala |
Fixed crash by pattern matching widened type before casting |
compiler/src/dotty/tools/dotc/core/NamerOps.scala |
Added conflict detection for term-before-capture parameter ordering |
compiler/src/dotty/tools/dotc/reporting/messages.scala |
Enhanced error message handling for capture-set conflicts |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Fixes #25025
This PR fixes compiler crashes and adds proper error reporting when capture-set parameters (
[c^]) conflict with term definitions of the same name.Fixes
NoDenotation.ownercrash whencompanionClassreturnsNoSymbolClassCastExceptionintypedSingletonTypeTreewhen widened type isn't aTypeRefdef foo(c: AnyRef^)[c^]pattern (term param before capture param)Improvements
AlreadyDefinedmessage class to handle capture-set conflicts with proper error code (E161) and explanation