Skip to content

Fix handling of recursive bounds in constraints #9012

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

Merged
merged 2 commits into from
May 20, 2020

Conversation

smarter
Copy link
Member

@smarter smarter commented May 20, 2020

No description provided.

smarter added 2 commits May 20, 2020 16:22
These can lead to deep subtype errors, this also fixes scala#8976 but see
also the next commit which fixes the underlying soundness issue.
`approximation` used to replace recursive occurences of the type
variable being instantiated by `TypeBounds.empty`, but this is not sound
in general since the approximation might be outside the bounds of the
type variable. We could try to do something fancy with
ApproximatingTypeMap but it seems complicated (and expensive) and
there's an easier solution: since last commit, only the upper bound is
allowed to be recursive, so we can just instantiate the type variable to
its lower bound to avoid the problem in a sound and cheap way.
@@ -87,6 +87,10 @@ trait ConstraintHandling[AbstractContext] {

protected def addOneBound(param: TypeParamRef, bound: Type, isUpper: Boolean)(using AbstractContext): Boolean =
if !constraint.contains(param) then true
else if !isUpper && param.occursIn(bound)
// We don't allow recursive lower bounds when defining a type,
// so we shouldn't allow them as constraints either.
Copy link
Contributor

Choose a reason for hiding this comment

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

I am not 100% sure about performance implications here. Let's test this.

@odersky
Copy link
Contributor

odersky commented May 20, 2020

test performance please

@odersky
Copy link
Contributor

odersky commented May 20, 2020

Yes, that looks like a much better way to fix #8976

@dottybot
Copy link
Member

performance test scheduled: 1 job(s) in queue, 0 running.

@dottybot
Copy link
Member

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/9012/ to see the changes.

Benchmarks is based on merging with master (43e4bfa)

@smarter
Copy link
Member Author

smarter commented May 20, 2020

I think it's within the usual variance but we can run again to check

@smarter
Copy link
Member Author

smarter commented May 20, 2020

test performance please

@dottybot
Copy link
Member

performance test scheduled: 1 job(s) in queue, 0 running.

@dottybot
Copy link
Member

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/9012/ to see the changes.

Benchmarks is based on merging with master (43e4bfa)

@smarter smarter merged commit 38272aa into scala:master May 20, 2020
@smarter smarter deleted the fix-instantiation branch May 20, 2020 20:32
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.

3 participants