Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

lrytz
Copy link
Member

@lrytz lrytz commented Sep 10, 2025

The test causes a subtyping test that loops, which is caught by existing infrastructure (LogPendingSubTypesThreshold). However, before reaching the threshold the subtyping check branches off into two equal cases at every iteration. For details, see the bug report.

To avoid having to reach the threshold on every one of these branches, remember the problematic subtyping tests on the way back.

Fixes scala/bug#13119

@scala-jenkins scala-jenkins added this to the 2.13.17 milestone Sep 10, 2025
The test causes a subtyping test that loops, which is caught by existing
infrastructure (LogPendingSubTypesThreshold). However, before reaching
the threshold the subtyping check branches off into two equal cases
at every iteration. For details, see the bug report.

To avoid having to reach the threshold on every one of these branches,
remember the problematic subtyping tests on teh way back.
try {
pendingSubTypes += p
isSubType1(tp1, tp2, depth)
} finally {
pendingSubTypes -= p
}
} else if (!knownFalseSubTypes.isEmpty && knownFalseSubTypes.get(tp1).contains(tp2)) {
Copy link
Member

Choose a reason for hiding this comment

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

Should we avoid the option allocation with getOrElse?

Copy link
Member Author

Choose a reason for hiding this comment

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

The option allocation is only when there's an entry, which is rare. And with getOrElse there's a Function allocation, no?

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.

Compiler hangs in TypeComparers (via inferTypedPattern)
3 participants