Skip to content

Commit

Permalink
Comment and diagnostic printing when lowering nestingLevel
Browse files Browse the repository at this point in the history
  • Loading branch information
odersky committed Aug 19, 2022
1 parent 4649fd9 commit 06336a2
Showing 1 changed file with 9 additions and 1 deletion.
10 changes: 9 additions & 1 deletion compiler/src/dotty/tools/dotc/core/ConstraintHandling.scala
Original file line number Diff line number Diff line change
Expand Up @@ -501,7 +501,7 @@ trait ConstraintHandling {
else if tp.nestingLevel > maxLevel then
if variance > 0 then nestedVarsLo += tp
else if variance < 0 then nestedVarsHi += tp
else tp.nestingLevel = maxLevel
else
// For invariant type variables, we use a different strategy.
// Rather than instantiating to a bound and then propagating in an
// AvoidMap, change the nesting level of an invariant type
Expand All @@ -511,6 +511,14 @@ trait ConstraintHandling {
// `fixLevels`, this could lead to coarser types. But it has the potential
// to give a better approximation for the current type, since it avoids forming
// a Range in invariant position, which can lead to very coarse types further out.
// TODO: This widening is a side effect that is not undone if a typer state is aborted
// I don't think it's a soundness problem, since all that could happen is that
// the type variable causes earlier instantiations of other type variables
// down the line. But it could produce a hard-to-debug side effect that leads
// to worse types than expected. We should find a more robust way to do this.
// Maybe instantiating `tp` to another freshly created type at nesting level?
constr.println(i"widening nesting level of type variable $tp from ${tp.nestingLevel} to $maxLevel")
tp.nestingLevel = maxLevel
true
else false
case _ =>
Expand Down

0 comments on commit 06336a2

Please sign in to comment.