Revision fc8ddcfbccb1d3da7fb81bf9a5f97e7797a7cd11 authored by Slava Pestov on 20 January 2016, 08:51:11 UTC, committed by Slava Pestov on 20 January 2016, 08:55:05 UTC
With an upcoming patch we would call setMutating() on materializeForSet before computing the setter's isMutating() in the case where a setter was explicitly declared 'nonmutating'. Fix that by replacing the setter->isMutating() call with a direct computation of the expected result. It seems that the materializeForSet of protocol protocol requirements has to be mutating, even if the protocol is a class protocol or the property is nonmutating -- I need to investigate why and fix SILGen to not make this assumption, but in the meantime, opt-out of the new logic with protocol requirements to avoid more breakage.
1 parent 1ba8f45
0032-rdar19919421.swift
// RUN: not %target-swift-frontend %s -parse
class A : A { }
func doIt<T>(obj: AnyObject) -> T? {
return obj as? T
}
let result: A? = doIt(A()) as A?
Computing file changes ...