[swift-dev] Exclusivity checker hacking?

[John McCall]

> On Oct 5, 2017, at 6:34 PM, Jordan Rose via swift-dev <swift-dev at swift.org> 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.

The important point here is that the "conservatively emit static errors for every exclusivity check we can't resolve statically" rule is basically equivalent to "disallow mutable class properties", because we do not have any language support for the sort of unique-right-to-access rules that would be necessary to ever resolve any of those statically.

John.


> 
> 
>> 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.)
> 
> Jordan
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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