[swift-dev] Miscompile with protocol compositions

[Slava Pestov]

And here’s a test case that crashes at runtime in Swift 3.1 and asserts on an asserts-on build that does not involve protocol compositions, only protocol refinement and a class constraint:

protocol P {
  func bar()
}

// Comment out the 'class ,' to make the problem go away
protocol Q : class, P {}

extension P {
  mutating func foo() {
    bar()
  }
}

class C : Q {
  let x: Int = 100

  func bar() {
    print(x) // crash here
  }
}

func takesQ(q: Q) {
  var qq = q
  qq.foo()
}

takesQ(q: C())

> On Apr 27, 2017, at 12:35 AM, Slava Pestov via swift-dev <swift-dev at swift.org> wrote:
> 
> Hi all,
> 
> I’ve spent most of the last two days debugging various issues with property and subscript accesses on class-constrained existentials and I’ve just now realized the root cause is a much more fundamental issue.
> 
> Consider the following code:
> 
> protocol P {
>  var x: Int { get set }
> 
>  init()
> }
> 
> func takesP(p: inout P & AnyObject) {
>  p.x = 1
> }
> 
> Note that ‘takesP’ has a class-constrained existential type as a parameter. You can replace AnyObject with any class protocol, it won’t change anything below.
> 
> Also, the init() requirement in the protocol will come into play later — for now, just consider the ‘var x’, which has a mutating setter.
> 
> The above code compiles fine. Let’s take a look at the SILGen though:
> 
>  %2 = load [copy] %0 : $*AnyObject & P
>  %3 = open_existential_ref %2 : $AnyObject & P to $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P
> ...
>  %8 = alloc_stack $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P
>  store %3 to [init] %8 : $*@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P
>  %10 = witness_method $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P, #P.x!setter.1, %3 : $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (Int, @inout τ_0_0) -> ()
>  %11 = apply %10<@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P>(%7, %8) : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (Int, @inout τ_0_0) -> ()
> 
> So we load the ‘AnyObject & P’ existential value from our inout argument, then in order to call the protocol requirement for x’s setter, which takes the ‘self’ value as an indirect argument, we allocate a box on the stack, store the reference into the box, call the requirement with the address of the box as the value of ‘self’, and destroy the box. We never write the result back to the inout.
> 
> So consider the following implementation of a concrete type conforming to P:
> 
> extension P {
>  var x: Int {
>    get { return 0 }
>    set {
>      self = Self()
>    }
>  }
> }
> 
> class C : P {
>  required init() {}
> }
> 
> Note that the mutating setter for ‘x’ assigns to ‘self’, which is totally fine — it’s defined in a protocol extension of a non-class protocol P.
> 
> Let’s try to use our concrete class type with our function takesP():
> 
> let c = C()
> var cc = c
> 
> takesP(p: &cc)
> 
> print(c === cc)
> 
> When you compile and run this, it outputs ‘true’, which is not what you would expect from reading the code, since the setter re-assigns ‘self’.
> 
> Ok, maybe we can just tell people that if your class conforms to a non-class protocol, then assignments to ‘self’ inside implementations of the protocol requirement are not allowed, and are silently dropped.
> 
> Now look at how we compile this version of takesP:
> 
> extension P {
>  mutating func foo() {
>    self = Self()
>  }
> }
> 
> func takesP(p: inout P & AnyObject) {
>  p.foo()
> }
> 
> Here instead of calling a mutating setter, we call a mutating method.
> 
> If we look at the SILGen, there is no stack allocation anymore, instead we pass the class reference directly as an inout argument, which is wrong:
> 
>  %7 = open_existential_ref %6 : $AnyObject & P to $@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & P
>  %8 = witness_method $@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & P, #P.foo!1, %7 : $@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & P : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (@inout τ_0_0) -> ()
>  %9 = apply %8<@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & P>(%7) : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (@inout τ_0_0) -> ()
> 
> In a no-asserts build, like Swift 3.1 GM, this produces a binary which crashes at runtime. In an asserts build, we hit an assertion in Sema:
> 
> Assertion failed: (fromType->is<LValueType>() && "Can only convert lvalues to inout"), function coerceObjectArgumentToType, file /Users/slava/new/swift/lib/Sema/CSApply.cpp, line 6336.
> 
> There seem to be two fundamental problems here:
> 
> 1) Sema models the base expression of a mutating member as an RValue, because it checks if the base expression type has reference semantics, not the *self type of the member*.
> 
> 2) SIL cannot express an inout access performed on the payload of class existential.
> 
> #1 is easy enough to fix, and allows my code examples involving subclass existentials to type check without hitting the LValue assertion.
> 
> #2 is more fundamental. At first I thought it would be sufficient to change SILGen to only use class existential representation for protocol compositions where *all* members are class-constrained, instead of protocol compositions where *any* member is class-constrained. However this is insufficient because a class-constrained protocol can refine a non-class constrained protocol.
> 
> We could say that a class-constrained protocol only uses class existential representation if all protocols it inherits also use class existential representation. Basically, split up ProtocolDecl::requiresClass() into two predicates — the current requiresClass() that expresses a constraint in the formal type system, and a stricter requiresNonMutatingSelfAccess() or similar which expresses that requirements and extension methods cannot be ‘mutating’. The latter would only be true if all refined protocols are also class constrained, and would be the condition for using a class existential representation.
> 
> Now the reason the first example generates valid (but surprising) SIL, while the second one crashes, is that we seem to have a hack somewhere to handle mutating property access on a non-mutating value by consing up a box, copying the value into the box, and tearing down the box. We could conceivably generalize this hack to work on mutating methods as well, but it would lead to the same surprising behavior where the assignment to ’self’ is ‘lost'.
> 
> However, there would be no loss of efficiency in that case, as we would still use the class existential representation in all the cases where we can currently use it.
> 
> Another potential fix is to simply disallow mutating methods from being called on class-constrained existentials altogether, but that is a source breaking change (even though the old behavior was extremely flaky).
> 
> Any thoughts?
> 
> Slava
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev