Sema: Diagnose completely unapplied references to mutating methods. #17642
Conversation
|
@swift-ci Please test |
|
@jckarter Since we always miscompile to undefined behavior, a warning sounds dangerous. Why not error out unconditionally? |
|
Build failed |
|
Build failed |
|
It feels a little late to spring new hard source breaks on users in 4.2 to me. I could ask though. |
The currying behavior of method references completely breaks in the face of `inout` semantics, even moreso with exclusivity enforcement, but we failed to diagnose these references in Swift 4 and previous versions. Raise a compatibility warning when these references are found in Swift 4 code, or error in Swift 5 and later. Simplify the partial application logic here slightly too now that standalone functions do not allow currying. Addresses rdar://problem/41361334 | SR-8074.
jckarter
force-pushed
the
no-unapplied-mutating-method-references
branch
from
cc90528
to
28fc7b0
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
|
@jckarter Fair enough. |
|
The core team agreed that a compatibility warning is the right approach here. |
|
@jckarter This patch seems to break LLDB's build because it uses |
|
@brentdax This patch didn't do anything to change |
|
@jckarter You're right, I'm sorry. I must have mixed up tabs while I was tracing it down. |
The currying behavior of method references completely breaks in the face of
inoutsemantics, even moreso with exclusivity enforcement, but we failed to diagnose these references in Swift 4 and previous versions. Raise a compatibility warning when these references are found in Swift 4 code, or error in Swift 5 and later. Simplify the partial application logic here slightly too now that standalone functions do not allow currying. Addresses rdar://problem/41361334 | SR-8074.