[4.2][CSRanking] Swift 4.1 compatibility hack for favouring properties on concrete types over protocols #19288
Conversation
…concrete types over protocols Changes in shadowing behaviour by swiftlang#15412 caused a property on a concrete type to no longer shadow a protocol property member, which created unintentional ambiguities in 4.2. This commit ensures we at least keep these cases unambiguous in Swift 5 under Swift 4 compatibility mode. This is intentionally narrow in order to best preserve source compatibility under Swift 4 mode by ensuring we don't introduce any new ambiguities. Resolves SR-7425, SR-7940 & SR-8343.
Update the patch to account for a couple of master changes that aren't in 4.2: - `getAsNominalTypeOrNominalTypeExtensionContext` was renamed to `getSelfNominalTypeDecl` - Superclass constrained protocols aren't implemented
|
@swift-ci Please smoke test |
|
@swift-ci Please test source compatibility |
|
@swift-ci please test |
|
Build failed |
|
@rudkx Looks like the Linux test timed out, could you try again? |
|
@swift-ci Please smoke test Linux platform |
|
@rudkx As I understand it, it's the full Linux test that needs re-running – could you please kick it off? |
|
Ah yes, I always reach for the "saved reply" for smoke testing. |
|
@swift-ci Please test Linux platform |
|
Any news on this (and #19562)? I don't know when the cut off point for getting stuff into 4.2.1 is, so I don't know how urgent it is. |
|
I sincerely apologize for now seeing this sooner, and I appreciate you filing the PR. Swift 4.2.1 is a very focused release, and there are always a chance of regressions being introduced by changes like this. We should hold this fix to Swift 5. |
(4.2 cherry-pick of #18952)
Explanation: For some protocol
Pand non-conforming classCwhere both types declare a propertyfoo, in contexts where members from bothCandPare accessible, an access tofoowould be considered ambiguous.Scope: Resolves a 4.2 source compatibility regression.
SR Issue: SR-7425
Risk: Low – the added logic is narrow and specifically designed not to introduce any new ambiguities.
Testing: Added tests for Swift 4 property overloading behaviour, Test suite, Compatibility suite
Reviewers: @rudkx