Skip to content
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

Fix #11078: avoid widening F-bounds in type avoidance #11192

Merged
merged 3 commits into from
Jan 27, 2021

Conversation

liufengyun
Copy link
Contributor

@liufengyun liufengyun commented Jan 22, 2021

Fix #11078: avoid widening F-bounds in type avoidance

@liufengyun liufengyun changed the title Fix #11078: avoid widening bounds in type avoidance Fix #11078: avoid widening F-bounds in type avoidance Jan 22, 2021
@@ -462,6 +462,34 @@ object TypeOps:
else
range(defn.NothingType, defn.AnyType)
}

/** Deviation from standard tryWiden:
* - Don't widen F-bounds
Copy link
Member

Choose a reason for hiding this comment

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

Maybe the standard tryWiden shouldn't widen f-bounds either?

Copy link
Contributor Author

@liufengyun liufengyun Jan 22, 2021

Choose a reason for hiding this comment

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

Yes, this is a trial to see how it works. It may incur a performance penalty.

If it works, I think we need a more systematic approach here: possible a field in SymDenotation to cache whether a symbol is F-bounded. The field can be set in checkNonCyclic, so we can avoid the computation here (or in ApproximatingTypeMap).

Copy link
Contributor

@odersky odersky Jan 24, 2021

Choose a reason for hiding this comment

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

F-bounded situations are already captured by LazyRefs. Maybe just add a case for LazyRefs to TypeOps.avoid?
Oh, I see you tried that already.

@@ -438,6 +438,8 @@ object TypeOps:
tp.origin, fromBelow = variance > 0 || variance == 0 && tp.hasLowerBound)(using mapCtx)
val lo1 = apply(lo)
if (lo1 ne lo) lo1 else tp
case tp: LazyRef =>
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should be emptyRange instead of TypeBounds.empty.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the tip, @odersky. I tried emptyRange, the test tests/run/i2895a.scala still fails. The problem is that LazyRef may leak into non-bounds places after asSeenFrom. It seems we need to stop earlier in the handling of bounds.

@liufengyun
Copy link
Contributor Author

test performance please

@dottybot
Copy link
Member

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

@dottybot
Copy link
Member

Performance test finished successfully:

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

Benchmarks is based on merging with master (35bb073)

@liufengyun
Copy link
Contributor Author

@odersky Could you have a look at the last trial? Does it make sense?

Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

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

That looks like a clean fix.

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.

StackOverflow when wrapping F-Bound type
5 participants