-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Remove nested archetypes #40794
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove nested archetypes #40794
Conversation
@swift-ci please smoke test |
@swift-ci please test source compatibility |
@swift-ci please smoke test |
@swift-ci please test source compatibility |
f2749a7
to
63fcdad
Compare
@swift-ci please smoke test |
@swift-ci please test compiler performance |
@swift-ci please test source compatibility |
@swift-ci please test |
@swift-ci please test source compatibility |
Huh, it didn't pick up the llvm-project change. |
@swift-ci please test |
@swift-ci please smoke test |
@swift-ci please smoke test |
@swift-ci please test source compatibility |
@swift-ci please test compiler performance |
Perf test failed due to a UPASS:
|
This API is only used for dumping and verification, and is not intended to remain a meaningful query.
All non-nested archetype types already have a generic environment field, and nested archetype types will need one soon anyway on their way to irrelevance, so sinking the field doesn't isn't a net loss. While here, isolate the code that lazily creates and caches the environment, because only one subclass uses it (for opened archetypes) and I had inadvertently broke caching there recently.
We don't need lazy creation of generic environments for opaque archetypes, because they don't do much work up front. Make it eager, so we can move away from delayed generic environment creation entirely.
The most interesting one of these is `ArchetypeType::getRoot()`, which we reimplement in terms of getting the root generic parameter and then looking up the archetype in the generic environment.
…nvironment Rather that requiring parent archetypes to be stored at the time of construction, map the base of the interface type through the generic environment.
Instead of storing nested archetypes hierarchically in `ArchetypeType`, store them in a map (indexed by dependent member type) on the generic environment itself. With this, we no longer need to create archetypes for every type along the path, because archetypes are findable via generic environment + interface type.
`ArchetypeType` has all of the API we need for these cases, so use that instead to isolate us from `NestedArchetypeType`, which we would like to eliminate soon-ish.
As another step toward eliminating NestedArchetypeType, generalize the representation, construction, and serialization of primary and sequence archetypes to interface types, rather than generic parameter types.
It only made sense on the root, and clients that care can look at the interface type.
Form opened archetype types based on an interface type and existential type, rather than assuming all OpenedArchetypeType instances only represent the root. Sink the UUID, existential type, and actual creation of the opened archetype into the opened generic environment, so we consistently only create new archetype instances from the generic environment. This slims down OpenedArchetypeType and makes it work similarly to the other archetype kinds, as well as generalizing it to support nested types. Sink the existential type and UUID of an
It's no longer used from the outside, yay!
This makes more code agnostic to the presence of NestedArchetypeType.
Nested archetypes are represented by their base archetype kinds (primary, opened, or opaque type) with an interface type that is a nested type, as represented by a DependentMemberType. This provides a more uniform representation of archetypes throughout the frontend.
63fcdad
to
452ecca
Compare
@swift-ci please smoke test |
@swift-ci please test |
Eliminate
NestedArchetypeType
from the type system, which was used to represent archetypes for types likeC.Element
. Instead, encode all archetype types as the base archetype type (primary, opened, or opaque) and an interface type describing the path to that archetype. This involves a number of changes:PrimaryArchetype
,OpenedArchetypeType
, andOpaqueTypeArchetypeType
to use their interface types and generic environment for queries.OpenedArchetypeType
andOpaqueTypeArchetypeType
to deal with arbitrary interface types, which simplifies handling of nested types for these cases.