Open swift-ci opened 4 years ago
Hmm, it seems like we're incorrectly computing the type of the backing storage. We do correctly find the nominal type associated with the attribute (because we look for protocol members as well), but it looks like during type resolution for the attribute, we're calling resolveTopLevelIdentTypeComponent
which finds protocol Bar
only. I think we should be including protocol members as well, so we can find the typealias Bar
.
Comment by Vatsal Manot (JIRA)
@theblixguy is this an easy fix? I'm afraid I don't have much C++ experience, but if it's an easy patch I can try my hand at it.
@swift-ci create
Environment
Big Sur developer beta 4 Xcode 12 beta 4 Swift 5.3Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug, PropertyWrappers, TypeChecker | |Assignee | None | |Priority | Medium | md5: 0e20853ceeffae474ce696885650b09fIssue Description:
The example below demonstrates the bug. Here, Bar is used both as a top-level name for a protocol, and a name for a typealias to a property wrapper (defined in a protocol extension).
When using property wrappers, the Bar typealias is expected to resolve to the property wrapper but instead it resolves to the top-level protocol.
In the following example, "x0" will not compile while "x1" will - even though they semantically point to the same property wrapper.
protocol Bar {
{{ }}
{{}}}
{{ }}
@propertyWrapper
struct Baz: Bar {
{{ var wrappedValue: Void}}
{{ }}
{{ init() {}}
{{ wrappedValue = ()}}
{{}}}
{{ }}
protocol FooProtocol {
{{ }}
{{}}}
{{ }}
extension FooProtocol {
{{ typealias Bar = Baz}}
{{ typealias BarNonConflictingName = Baz}}
{{}}}
{{ }}
struct Foo: FooProtocol {
{{ @Bar var x0: Void}}
{{ @BarNonConflictingName var x1: Void}}
{{}}}