Skip to content

Conversation

@bracevac
Copy link
Contributor

@bracevac bracevac commented Jan 21, 2026

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

  • Namer.scala: Fixed NoDenotation.owner crash when companionClass returns NoSymbol
  • Typer.scala: Fixed ClassCastException in typedSingletonTypeTree when widened type isn't a TypeRef
  • NamerOps.scala: Added conflict detection for def foo(c: AnyRef^)[c^] pattern (term param before capture param)

Improvements

  • Enhanced AlreadyDefined message class to handle capture-set conflicts with proper error code (E161) and explanation

@bracevac bracevac changed the title Fix crash in checkNoConflict Fix Crashes when Capture-set Parameters Conflict with Terms Jan 21, 2026
@bracevac bracevac requested review from noti0na1 and odersky January 21, 2026 22:03
@bracevac
Copy link
Contributor Author

Perhaps we should also rule out nonsense like def foo[c^](x: c) = ..., but that's going to be more involved.

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
Copy link
Member

@noti0na1 noti0na1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

Copilot AI left a 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.owner crash by using .orElse() when companionClass returns NoSymbol
  • Fixed ClassCastException by adding pattern matching to handle cases where widened type is not a TypeRef
  • Added proactive conflict detection in addDummyTermCaptureParam to 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CC: Crash when a Method's Capture Variable and Parameter are Identically Named

3 participants