[swift-dev] Exclusivity checker hacking?

[David Zarzycki]

> On Oct 5, 2017, at 18:34, Jordan Rose <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.)

This has been very helpful. Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171005/7b10f780/attachment.html>