fix: Apply adjustments to proper expr when invoking CoerceMany
#19111
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.
Fixes #19021
I think that this issue was quite hard to find (I wonder how David found this out 😄 )
For instance, removing lang item annotation
#[lang = "owned_box"]
, making the last expression of thefn main()
into a plain match expression instead of a closure, or annotating the closure return type to the following code won't trigger the issue.The path in which above code triggers the issue is quite interweaven, but the root cause is that we are applying resulting adjustments of the
CoreceMany
to the wrong expression; we are applying it always to the very expression that we are coercing from.If the next arm/branch of the
CoerceMany
can coerce into the previousmerge_ty
, this is not a problem.But if the previous
merge_ty
has to be coerced into the type of next arm/branch, the adjustments must be applied to the previousCoerceMany
expressions.So, in the above code, when calling
CoerceMany::coerce
with the second arm, the match expression's type is inferred as&Foo
and the first branch must be coerced into it.But adjustments for this coercion
[Deref, Deref, Borrow]
is applied to the next arm,y
, and sincey = &Foo
cannot be dereferenced twice, and this causes the issue.