Skip to content

Conversation

@odersky
Copy link
Contributor

@odersky odersky commented Nov 25, 2025

The first commit gives a better error message for box failures. At least we don't get

Note that cap is not included in {}

anymore. To make this even better we'd have to trace back a box failure to the original types we were trying to compare. Right now the box failure error notes are too disconnected from the rest. But they become clearer when one compiles with -explain.

The second commit fixes the underlying problem. The neg tests are now pos tests. I kept the special error message for better diagnosis if the mismatch arises elsewhere. The mismatch still persists in eta.scala. We should investigate
whether that's legit or not.

Fixes #24543

@odersky odersky changed the title Somewhat better error notes for box failures Avoid box failures and better diagnoses if they come back Nov 27, 2025
@odersky odersky requested a review from Linyxus November 27, 2025 10:01
@odersky odersky changed the title Avoid box failures and better diagnoses if they come back Avoid box failures and better diagnosis if they come back Nov 27, 2025
Copy link
Contributor

@Linyxus Linyxus left a comment

Choose a reason for hiding this comment

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

Otherwise LGTM!

val (boxed, unboxed) =
if cs.tp1.isBoxedCapturing then (cs.tp1, cs.tp2) else (cs.tp2, cs.tp1)
i"""${cs.tp1} does not conform to ${cs.tp2} because $boxed is boxed but $unboxed is not.
|This could be an error in the capture checker implementation."""
Copy link
Contributor

@Linyxus Linyxus Nov 27, 2025

Choose a reason for hiding this comment

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

Not sure about this error note. It feels to me a bit ambiguous: should the user open an issue ticket when they see this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are not sure whether it's an error or not, so I refrained from giving clear guidance to users.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In fact eta.scala still shows the same error.

At least we don't get

    Note that cap is not included in {}

anymore. To make this even better we'd have to trace back a box
failure to the original types we were trying to compare. Right now
the box failure error notes are too disconnected from the rest. But
they become clearer when one compiles with -explain.
The neg tests are now pos tests. I kept the special error message for better diagnosis
if the mismatch arises elsewhere (it does in eta.scala).
@odersky odersky merged commit 9aa08e2 into scala:main Nov 29, 2025
45 checks passed
@odersky odersky deleted the fix-24543 branch November 29, 2025 10:08
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.

Very obscure error message when cause is unboxing of parameter bounds

2 participants