-
Notifications
You must be signed in to change notification settings - Fork 10.5k
In Swift 3/4 mode, continue treating 'lazy override' as an override #13335
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
In Swift 3/4 mode, continue treating 'lazy override' as an override #13335
Conversation
@swift-ci Please test |
And, to try to rule out me breaking anything subtle… @swift-ci Please test source compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, but you might want to follow up on the hack at some point.
lib/Sema/TypeCheckDecl.cpp
Outdated
// HACK: We would normally do this at the end of validation, but | ||
// if we wait that long then the getter doesn't get marked as an | ||
// override. | ||
maybeAddAccessorsToVariable(cast<VarDecl>(overrideASD), TC); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trivial getters are created in CodeSynthesis.cpp, maybe we should mark them as overrides there if the AbstractStorageDecl overrides something? Up until now this could not happen because trivial accessors are only created for stored properties and lazy properties which normally don't override anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, that might make more sense. I could see maybeAddAccessorsToVariable
depending on something earlier in validation.
Build failed |
55ba432
to
64f49ff
Compare
@swift-ci Please test |
Build failed |
@swift-ci Please test source compatibility |
Build failed |
Well, didn't get that right either. I'm not going to have time to work on this until the afternoon. |
Follow-up for 7c707ce. Without this, the declaration would be accepted, but any uses of the overridden property would be treated as ambiguous because the property wouldn't really be marked as an override. rdar://problem/35900345
64f49ff
to
f62f94d
Compare
This is definitely becoming a bigger change than just @swift-ci Please test |
@swift-ci Please test source compatibility |
Build failed |
@swift-ci Please smoke test compiler performance |
Build failed |
@swift-ci Please test source compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
…wiftlang#13335) Follow-up for 7c707ce. Without this, the declaration would be accepted, but any uses of the overridden property would be treated as ambiguous because the property wouldn't really be marked as an override. rdar://problem/35900345 (cherry picked from commit ca9d5a9)
Follow-up for #13304. Without this, the declaration would be accepted, but any uses of the overridden property would be treated as ambiguous because the property wouldn't really be marked as an override.
"Oops."
rdar://problem/35900345