Skip to content

Map cap to fresh in capture sets #23184

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

Closed
wants to merge 8 commits into from
Closed

Conversation

odersky
Copy link
Contributor

@odersky odersky commented May 19, 2025

Fixes #23170

This was disabled before. We also had to slightly extend fresh/cap collapsing
to make override checks go through under the new scheme.

Based on #23182. Only last commit is new.

Copy link
Contributor

@natsukagami natsukagami left a comment

Choose a reason for hiding this comment

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

LGTM (only looked at the last commit)

@odersky
Copy link
Contributor Author

odersky commented May 20, 2025

Does anyone want to review the other changes? If not I propose we merge the whole thing and we do a mentoring session soon on the new design.

@odersky odersky mentioned this pull request May 20, 2025
odersky added 8 commits May 21, 2025 16:40
Note i15923 does not signal a leak anymore. I moved it and some variants to pending.
Note: There seems to be something more fundamentally wrong with this test: We get an
infinite recursion for variant i15923b.
There was some accidental type confusion which made every capture root type end up
with cap as pathRoot and caps as pathOwner.
Split out Capability from Type. For now we keep most of the overall structure. E.g. capability handling code is
in file CaptureRef.scala. We will change this afterwards in separate refactorings.
Fixes scala#23170

This was disabled before. We also had to slightly extend fresh/cap collapsing
to make override checks go through under the new scheme.
Linyxus added a commit that referenced this pull request May 21, 2025
This fixes problems encountered for #15923 where we got infinite
recursions
caused by infinite streams of new ResultCap instances that were added to
capture sets.
The analysis of the problem showed that there is a cycle of dependencies
involving
both forwards and backwards propagations of ResultCap instances between
BiMapped capture sets linked by SubstBindingMaps. Each propagation would
create a new derived ResultCap instance.

We could try to solve the problem by having SubstBindingMaps remember
their mappings
and have their inverses work backwards. But that could still produce an
infinite stream
if there was a cycle of SubstBindingMaps of length > 2. So we fix the
problem at the
root by allowing only one derived ResultCap instance per original
ResultCap / binder pair.

Fixes #15923

Based on #23184. Only last commit is new.
@odersky
Copy link
Contributor Author

odersky commented May 21, 2025

Superseded by #23198

@odersky odersky closed this May 21, 2025
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.

Capture set parameters upper bounded by cap.rd cannot be widened to cap.rd
2 participants