Interpolate any type vars from comparing against SelectionProto #16348
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.
If the method being selected is polymorphic, then it is added, along
with fresh type vars, to the constraint. Normally this is fine, because
when the selection is then applied, the type vars are interpolated
(during tree simplification). But if the method being selected is a
macro that's being jointly compiled, then the compilation may be
suspended, which leaves a trailing type lambda in the constraint.
I tried addressing this in a few different ways. Initially with an
exemption in TreeChecker, but that seemed too remote and too liberal.
Later I tried addressing it specifically in inlining (in inlineIfNeeded)
but that also seemed too remote and extensive. In the end I thought
handling this around the testSubType call seemed most suitable.
Interpolating on all the new type vars in general is too eager, so I
ended up guarding it only for SelectionProto, sadly.