Various existential l-value fixes #9864
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
This is an LValue component whose value is the class reference inside of a class existential. Unlike OpenOpaqueExistentialComponent, this is a logical component, with a "writeback" consisting of wrapping the new class reference in a class existential having the same conformances as the original. This is slightly awkward, but adding "by-address" operations on class existentials, and projecting the payload out is a big change and might not make sense for other reasons.
…s as lvalues This is part of allowing lvalue access on class existential payloads.
…Exprs with lvalue base
…ntials This is pretty awkward. If an lvalue has an open existential as its RValue type, we would emit an alloc_stack instruction holding the materialized temporary before we emitted the value itself. This introduced a def-after-use violation because the open existential type in the stack allocation was not dominated by its definition. To get around this, don't use an SGFContext to emit the 'get' in-place. There's no performance degradation, because the only time we will attempt materializing an lvalue with an open existential type is when performing an lvalue access of a class existential payload, and here we in-place initialization makes no difference since the value is a single reference.
rdar://32288618
|
@swift-ci Please test. |
|
@slavapestov Does this seem at all reasonable? |
|
LGTM. |
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.
There are a variety of problems with SILGen for class and metatype existential values held in mutable variables. Those problems are currently masked for class types by a quirk of Sema, which we are not proposing to change in swift-4.0-branch. However, they are exposed for metatype values, leading to crashes in SILGen.
This combines #9637 and #9852 for swift-4.0-branch. It fixes rdar://32288618.
This patch affects code generation for mutable existential l-values. Because of the quirk in Sema, its largest impact is on existential metatypes: specifically, when they're held in mutable variables.
The risk is fairly low. This patch does change some important code paths, but they are relatively well-tested for the most important cases. The main case affected otherwise is the existential-metatype case, which currently just doesn't compile at all.
This has been tested with our full regression test suite.