Fix inconsistent typeSize calculation for TupleN vs recursive pair encodings
#24743
+29
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Lluc24
changed the title
typeSize calculation for TupleN vs recursive pair encodings
Previously, `typeSize` reported different values for standard `TupleN` types (e.g., `(A, B)`) compared to their equivalent recursive pair encodings (e.g., `A *: B *: EmptyTuple`). This discrepancy occurred because `TupleN` is a flat `AppliedType`, while the nested encoding forms a deeper tree structure. This patch modifies `TypeSizeAccumulator` to canonicalize `TupleN` types into their recursive `*:` representation before calculating the size. This ensures that the size metric is consistent regardless of whether the tuple is represented syntactically or structurally. This change is verified by a new unit test in `TypesTest`, which confirms that both `Tuple3[Int, Boolean, Double]` and its recursive equivalent `Int *: Boolean *: Double *: EmptyTuple` now yield identical `typeSize` values. Fixes scala#24730
Lluc24
force-pushed
the
i24730-TupleN-wrong-typeSize
branch
from
cd3a120 to
dca3ea1
Compare
Member
|
We could maybe use scala3/compiler/src/dotty/tools/dotc/core/TypeUtils.scala Lines 148 to 157 in f67a1a0 |
mbovel
reviewed
Dec 14, 2025
Comment on lines
7137
to
7138
| val tpNorm = tp.tryNormalize | ||
| if tpNorm.exists then apply(n, tpNorm) |
Member
There was a problem hiding this comment.
Suggested change
| val tpNorm = tp.tryNormalize | |
| if tpNorm.exists then apply(n, tpNorm) | |
| val tpNorm = tp.normalized.normalizedTupleType | |
| if tpNorm ne tp then apply(n, tpNorm) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently,
typeSizereports inconsistent values for standard tuple types (e.g.,(A, B)) compared to their semantically equivalent recursive pair encodings (e.g.,A *: B *: EmptyTuple).This discrepancy arises because
TupleNis represented as a flatAppliedType, whereas the nested encoding forms a deeper tree structure. AstypeSizeis often used as a heuristic for complexity or optimization limits, this inconsistency can lead to divergent behavior in the compiler depending on how a tuple is represented syntactically.This PR modifies
TypeSizeAccumulatorto canonicalizeTupleNtypes into their recursive*:representation before calculating their size. This ensures that the size metric is consistent regardless of whether the tuple is represented as a flatAppliedTypeor a nested structural type.I have added a new unit test in
TypesTestthat assertsTuple3[Int, Boolean, Double]andInt *: Boolean *: Double *: EmptyTupleboth yield identicaltypeSizeequal to 3.Thanks to @mbovel for providing the unit test that effectively reproduces this issue and validates the fix.
Fixes #24730