SIL: Fix zealous assert in verifier

[aschwaighofer]

A materialize for set / write-back sequence is not really mutating the opened existential

rdar://36799163

[aschwaighofer]

@swift-ci Please smoke test and merge

[aschwaighofer]

@jckarter Can you review for swift-4.1-branch?

[aschwaighofer]

@jckarter Andy reviewed it here #14134

[jckarter]

This is fine for 4.1, but how hard is it to fix SILGen to generate the materializeForSet callback with the right parameter convention in master? Or does that not matter after @rjmccall lands accessor coroutines?

[aschwaighofer]

I don't know. I have filed rdar://problem/36867783 for this (to fix SILGen).

[aschwaighofer]

Do we even need to emit a write back in the case of a non-mutating set? Semantically -- at first thought -- it must be a identity operation on memory?
For symmetry, I guess the write-back thunk could be a no-op.

[rjmccall]

A setter being nonmutating means that it doesn't change the value of self, not that it's guaranteed to semantically be a no-op. The most obvious examples are reference types like classes and UnsafeMutablePointer.

[aschwaighofer]

right, so the write-back for a non-mutating set is a no-op on the memory of self. (that is what i meant by identity operation -- the value not being mutated in case of references or pointers is the reference or pointer)

[aschwaighofer]

all the mutation on general heap memory happens as part of the materializeForSet operation not on the write back.

[rjmccall]

There should not be a writeback on the base l-value, yes.