Skip to content

Commit 06336a2

Browse files
committed
Comment and diagnostic printing when lowering nestingLevel
1 parent 4649fd9 commit 06336a2

File tree

1 file changed

+9
-1
lines changed

1 file changed

+9
-1
lines changed

compiler/src/dotty/tools/dotc/core/ConstraintHandling.scala

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -501,7 +501,7 @@ trait ConstraintHandling {
501501
else if tp.nestingLevel > maxLevel then
502502
if variance > 0 then nestedVarsLo += tp
503503
else if variance < 0 then nestedVarsHi += tp
504-
else tp.nestingLevel = maxLevel
504+
else
505505
// For invariant type variables, we use a different strategy.
506506
// Rather than instantiating to a bound and then propagating in an
507507
// AvoidMap, change the nesting level of an invariant type
@@ -511,6 +511,14 @@ trait ConstraintHandling {
511511
// `fixLevels`, this could lead to coarser types. But it has the potential
512512
// to give a better approximation for the current type, since it avoids forming
513513
// a Range in invariant position, which can lead to very coarse types further out.
514+
// TODO: This widening is a side effect that is not undone if a typer state is aborted
515+
// I don't think it's a soundness problem, since all that could happen is that
516+
// the type variable causes earlier instantiations of other type variables
517+
// down the line. But it could produce a hard-to-debug side effect that leads
518+
// to worse types than expected. We should find a more robust way to do this.
519+
// Maybe instantiating `tp` to another freshly created type at nesting level?
520+
constr.println(i"widening nesting level of type variable $tp from ${tp.nestingLevel} to $maxLevel")
521+
tp.nestingLevel = maxLevel
514522
true
515523
else false
516524
case _ =>

0 commit comments

Comments
 (0)