-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Fix failing bounds check on default getter #18419
Conversation
The type arguments on the default argument had the wrong span, which means that they were getting bounds checked. This is in contrast the other other type arguments (the ones on check itself), which aren't bounds checked - by not passing the isZeroExtent guard in checkInferredWellFormed.
@@ -333,7 +333,7 @@ object Applications { | |||
// it's crucial that the type tree is not copied directly as argument to | |||
// `cpy$default$1`. If it was, the variable `X'` would already be interpolated | |||
// when typing the default argument, which is too early. | |||
spliceMeth(meth, fn).appliedToTypes(targs.tpes) | |||
spliceMeth(meth, fn).appliedToTypeTrees(targs.map(targ => TypeTree(targ.tpe).withSpan(targ.span))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this type of confusion occur somewhere else in code, but we just didn't notice it yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the question. By code, do you mean compiler code, or do you mean something about user's code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I wasn't clear. I meant in compiler code where we have something like .appliedToTypes(targs.tpes)
and actually needs to be constructed with span.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that I'm aware of. Looking now, perhaps the .appliedToTypes(patternTypes)
in quotes pattern should reuse the original pattern tree spans, but I'm not certain. I was thinking Martin would be able to tell if this is a reoccurring problem and how to best deal with it.
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it's a corner case (default getters have a hang of producing those). Cannot see at the moment other situations that would require a generalization.
The recursion limit bug is a different issue: #18263 |
Backports #18419 to the LTS branch. PR submitted by the release tooling. [skip ci]
Backports #18419 to the LTS branch. PR submitted by the release tooling. [skip ci]
The type arguments on the default argument had the wrong span, which
means that they were getting bounds checked. This is in contrast to the
other type arguments (the ones on check itself), which aren't
bounds checked - by not passing the isZeroExtent guard in
checkInferredWellFormed.