> On Oct 5, 2017, at 15:44, David Zarzycki <d...@znu.io> wrote: > > > >> On Oct 5, 2017, at 18:34, Jordan Rose <jordan_r...@apple.com >> <mailto:jordan_r...@apple.com>> wrote: >> >> >> >>> On Oct 5, 2017, at 15:23, David Zarzycki <d...@znu.io <mailto:d...@znu.io>> >>> wrote: >>> >>> >>> >>>> On Oct 5, 2017, at 18:08, Jordan Rose <jordan_r...@apple.com >>>> <mailto:jordan_r...@apple.com>> wrote: >>>> >>>> >>>> >>>>> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev >>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> As an experiment, I’d like to force the exclusivity checking logic to >>>>> always error at compile time, rather than a mix of compile time and run >>>>> time. Near as I can tell, there is no built in debugging logic to do this >>>>> (not even to warn when dynamic checks are added). Am I missing something? >>>>> Where would be the best place in the code to make the dynamic checker >>>>> error/warning at compile time? Would a warning be useful to others? Or >>>>> should I just keep this on a throwaway branch? >>>> >>>> It's worth noting that this is impossible in the general case: >>>> >>>> // Library.swift >>>> public class Foo { >>>> public var x: Int = 0 >>>> public init() {} >>>> } >>>> public func testExclusivity(_ a: Foo, _ b: Foo, by callback: (inout Int, >>>> inout Int) -> Void) { >>>> callback(&a.x, &b.x) >>>> } >>>> >>>> // Client.swift, compiled as a separate target >>>> let foo = Foo() >>>> testExclusivity(foo, foo) { $0 = 42; $1 = 8192 } >>>> >>>> That doesn't necessarily mean there aren't improvements to be made, but it >>>> might change your goals. >>> >>> >>> Hi Jordan, >>> >>> Thanks for writing the above code. Just to be clear, are you pointing out >>> that exclusivity checking through opaque code (like a library) is >>> problematic? Or that classes introduce their own aliasing challenges? Or >>> both? Or something else entirely? >> >> The former, really. Classes are just the most convenient way to get >> coincidental aliasing. >> >> >>> If we set aside resiliency for a second, couldn't the exclusivity checker >>> dynamically crash in the above scenario if two or more InOutExprs end up >>> resolving to the same address? If not, then why not? >> >> "If we set aside resiliency" isn't something that works today. Local builds >> don't actually have access to the SIL of any of their dependencies at the >> moment (for a handful of reasons). Opaque code really does have to be >> treated as opaque. >> >> (If this isn't convincing, then consider 'a' and 'b' coming directly from >> Objective-C code, where there's no exclusivity checking logic at all.) > > Right, that make sense. > > Let’s step back for a second. How comprehensive is the exclusivity checker > within a single/pure Swift module? As long as external modules aren’t > involed, is the model exhaustive? Or can some scenarios slip through both the > static and dynamic checking? (Again, just within a single pure Swift module.)
John or Devin would be better at answering this, but I believe that the combined static/dynamic model will catch everything except accesses through UnsafePointer (sure), accesses from C (sure), and accesses across threads (ouch). The last can be caught by TSan, though. One other caveat: I believe we turn off the dynamic checking completely under -O in the Swift 4 release. I'm not sure if there are plans to change that or if the cost of the check really is that bad. Jordan
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
