Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Sep 4, 2025

This PR started with a shocking discovery. We actually did not record this-references in use sets. Once this was fixed, some tests failed and the stdlib build broke with 20 errors. 18 of these were oversights that were not caught before and were easily fixed. 2 of them pointed to further capture checking problems. This caused a sequence of successive fixes until everything compiled again and all the tests made sense.

The order in the commits here is a bit different: We first apply the fixes to the stdlib and the compiler and then start recording uses of this. This is so that we don't have a failing build in intermediate steps.

These problems were discovered once we started recording uses of this references.
The recording is not yet part of this commit because it requires downstream bugfixes
in the compiler.
These fell through the cracks before since we only considered named outer refs.
But inner classes can have outer this references check needd to be tracked in
use sets.
Previously there was a boundary condition where this could be the case for outermost
classes.
A constructor should never capture `this`, the object it constructs.
Was shockingly missing before.
 - Charge the use set of the initializer to the class constructor
 - Charge the declared capture set to the class
@odersky odersky marked this pull request as ready for review September 4, 2025 19:46
@odersky odersky requested a review from a team as a code owner September 4, 2025 19:46
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!

@odersky odersky merged commit 6b100a7 into scala:main Sep 8, 2025
48 of 49 checks passed
@odersky odersky deleted the markFree-this branch September 8, 2025 06:59
odersky added a commit that referenced this pull request Sep 8, 2025
 - Propagate expected type into blocks

The level checking should do the proper avoidance so that local symbols
    would not leak into type variables of the expected type.

 - Don't automatically add a FreshCap owner to its hidden set
 - Don't use span capture sets for function types as the underlying set
 
Based on #23874
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.

2 participants