Skip to content

Tweak convertible implicits fix #18727

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 1 commit into from
Nov 13, 2023

Conversation

dwijnand
Copy link
Member

@dwijnand dwijnand commented Oct 19, 2023

Rather than widen in viewExists, widen earlier, past type lambda
parameters. This allows foo2 in i16453b2 from being listed as a
possible implicit, as appropriate.

Tweaks my fix in #18719.

@dwijnand dwijnand force-pushed the tweak-convertible-implicits-fix branch 2 times, most recently from 1972cac to 731ec42 Compare October 19, 2023 14:05
Rather than widen in viewExists, widen earlier, past type lambda
parameters.  This allows `foo2` in `i16453b2` from being listed as a
possible implicit, as appropriate.
@dwijnand dwijnand force-pushed the tweak-convertible-implicits-fix branch from 731ec42 to a175525 Compare October 20, 2023 07:52
@dwijnand dwijnand marked this pull request as ready for review October 20, 2023 14:00
@dwijnand dwijnand assigned odersky and unassigned dwijnand Oct 20, 2023
@dwijnand dwijnand requested a review from odersky October 20, 2023 14:00
@odersky
Copy link
Contributor

odersky commented Nov 13, 2023

Should that not be "widen later" instead of "widen earlier"?

Otherwise LGTM

@dwijnand
Copy link
Member Author

Well, my previous fix added a widen inside viewExists and now I'm widening before calling viewExists.

@dwijnand dwijnand merged commit 85908de into scala:main Nov 13, 2023
@dwijnand dwijnand deleted the tweak-convertible-implicits-fix branch November 13, 2023 20:43
odersky added a commit that referenced this pull request Dec 17, 2023
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.
@Kordyjan Kordyjan added this to the 3.4.0 milestone Dec 20, 2023
dwijnand pushed a commit to dwijnand/scala3 that referenced this pull request Feb 21, 2024
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)
dwijnand pushed a commit to dwijnand/scala3 that referenced this pull request Mar 5, 2024
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)
WojciechMazur added a commit that referenced this pull request Jun 23, 2024
Backports #18727 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants