SIL: More robust substituted function type lowering. #40112
Merged
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
jckarter
force-pushed
the
subst-type-lowering-by-abstraction-pattern
branch
from
87516cf to
b289847
Compare
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
Build failed |
This change separates out the formation of the generic signature and substitutions for a SIL substituted function type as a pre-pass before doing the actual function type lowering. The only input we really need to form this signature is the original abstraction pattern that a type is being lowered against, and pre-computing it should make the code less side-effecty and confusing. It also allows us to handle generic nominal types in a more robust way; we transfer over all of the nominal type requirements to the generalized generic signature, then when recursively visiting the bindings, we same-type-constrain the generic parameters used in those requirements to the newly-generalized generic arguments. This ensures that the minimized signature preserves any non-trivial requirements imposed by the nominal type, such as conditional conformances on its type arguments, same-type constraints among associated types, etc. This approach does lead to less-than-optimal generalized generic signatures getting generated, since nominal type generic arguments get same-type-bound either to other generic arguments or fixed to concrete types almost always. It would be useful to do a minimization pass on the final generic signature to eliminate these unnecessary generic arguments, but that can be done in a follow-up PR.
jckarter
force-pushed
the
subst-type-lowering-by-abstraction-pattern
branch
from
b289847 to
5c404ac
Compare
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
1 similar comment
|
@swift-ci Please test source compatibility |
jckarter
added a commit
to jckarter/swift
that referenced
this pull request
Nov 12, 2021
…ing. To minimize unnecessary abstraction changes, we only want to represent differences in types that provide interesting representation diversity, such as between concrete function types with indirect arguments and generic function types, but not so much between differently-generic function types. The original subst function type lowering would handle layout constraints by generalizing them to the most abstract form that has a similar calling convention, such as AnyObject -> _RefCountedObject. However, the new implementation in swiftlang#40112 moved the generic signature formation for function types earlier in the type lowering process, and much of type lowering was unaware of layout constraints other than `requiresClass`, so I backed off on that optimization to be able to land it. This adds the optimization back, and generalizes type lowering in other places to correctly handle other layout constraints.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This change separates out the formation of the generic signature and
substitutions for a SIL substituted function type as a pre-pass
before doing the actual function type lowering. The only input we
really need to form this signature is the original abstraction pattern
that a type is being lowered against, and pre-computing it should make
the code less side-effecty and confusing. It also allows us to handle
generic nominal types in a more robust way; we transfer over all of
the nominal type requirements to the generalized generic signature,
then when recursively visiting the bindings, we same-type-constrain
the generic parameters used in those requirements to the newly-generalized
generic arguments. This ensures that the minimized signature preserves
any non-trivial requirements imposed by the nominal type, such as
conditional conformances on its type arguments, same-type constraints
among associated types, etc.
This approach does lead to less-than-optimal generalized generic
signatures getting generated, since nominal type generic arguments
get same-type-bound either to other generic arguments or fixed to
concrete types almost always. It would be useful to do a minimization
pass on the final generic signature to eliminate these unnecessary
generic arguments, but that can be done in a follow-up PR.
Addresses rdar://84827656 | SR-15254