[swift-dev] Exclusivity checker hacking?

[Jordan Rose]

> On Oct 5, 2017, at 15:44, David Zarzycki <dave at znu.io> wrote:
> 
> 
> 
>> On Oct 5, 2017, at 18:34, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> 
>> 
>>> On Oct 5, 2017, at 15:23, David Zarzycki <dave at znu.io <mailto:dave at znu.io>> wrote:
>>> 
>>> 
>>> 
>>>> On Oct 5, 2017, at 18:08, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171005/0d99d605/attachment.html>