[swift-dev] CI outage tomorrow

[Nicole Jacque via swift-dev]

Hi All-

The CI bots on swift.org will be down temporarily, starting at 11 AM 
(California time) while we install the newest Xcode beta.  We’ll post a 
corresponding preview snapshot at that time as well. 

Thanks!
Nicole

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

[John McCall via swift-dev]

> On Sep 30, 2016, at 11:54 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
> The document attached below contains the first "Semantic ARC" mini proposal: 
> the High Level ARC Memory Operations Proposal.
> 
> An html rendered version of this markdown document is available at the 
> following URL:
> 
> https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html 
> 
> 
> 
> 
> # Summary
> 
> This document proposes:
> 
> 1. adding the `load_strong`, `store_strong` instructions to SIL. These can 
> only
>be used with memory locations of `non-trivial` type.

I would really like to avoid using the word "strong" here.  Under the current 
proposal, these instructions will be usable with arbitrary non-trivial types, 
not just primitive class references.  Even if you think of an aggregate that 
happens to contain one or more strong references as some sort of aggregate 
strong reference (which is questionable but not completely absurd), we already 
have loadable non-strong class references that this operation would be usable 
with, like native unowned references.  "load_strong %0 : $*@sil_unowned T" as 
an operation yielding a scalar "@sil_unowned T" is ridiculous, and it will only 
get more ridiculous when we eventually allow this operation to work with types 
that are currently address-only, like weak references.

Brainstorming:

Something like load_copy and store_copy would be a bit unfortunate, since 
store_copy doesn't actually copy the source operand and we want to have a 
load_copy [take].

load_value and store_value seem excessively generic.  It's not like non-trivial 
types aren't values.

One question that comes to mind: do we actually need new instructions here 
other than for staging purposes?  We don't actually need new instructions for 
pseudo-linear SIL to work; we just need to say that we only enforce 
pseudo-linearity for non-trivial types.

If we just want the instruction to be explicit about ownership so that we can 
easily distinguish these cases, we can make the rule always explicit, e.g.:
  load [take] %0 : $*MyClass
  load [copy] %0 : $*MyClass
  load [trivial] %0 : $*Int

  store %0 to [initialization] %1 : $*MyClass
  store %0 to [assignment] %1 : $*MyClass
  store %0 to [trivial] %1 : $*Int

John.

> 2. banning the use of `load`, `store` on values of `non-trivial` type.
> 
> This will allow for:
> 
> 1. eliminating optimizer miscompiles that occur due to releases being moved 
> into
>the region in between a `load`/`retain`, `load`/`release`,
>`store`/`release`. (For a specific example, see the appendix).
> 2. modeling `load`/`store` as having `unsafe unowned` ownership semantics. 
> This
>will be enforced via the verifier.
> 3. more aggressive ARC code motion.
> 
> # Definitions
> 
> ## load_strong
> 
> We propose three different forms of load_strong differentiated via flags. 
> First
> define `load_strong` as follows:
> 
> %x = load_strong %x_ptr : $*C
> 
>   =>
> 
> %x = load %x_ptr : $*C
> retain_value %x : $C
> 
> Then define `load_strong [take]` as:
> 
> %x = load_strong [take] %x_ptr : $*Builtin.NativeObject
> 
>   =>
> 
> %x = load %x_ptr : $*Builtin.NativeObject
> 
> **NOTE** `load_strong [take]` implies that the loaded from memory location no
> longer owns the result object (i.e. a take is a move). Loading from the memory
> location again without reinitialization is illegal.
> 
> Next we provide `load_strong [guaranteed]`:
> 
> %x = load_strong [guaranteed] %x_ptr : $*Builtin.NativeObject
> ...
> fixLifetime(%x)
> 
>   =>
> 
> %x = load %x_ptr : $*Builtin.NativeObject
> ...
> fixLifetime(%x)
> 
> `load_strong [guaranteed]` implies that in the region before the fixLifetime,
> the loaded object is guaranteed semantically to remain alive. The fixLifetime
> communicates to the optimizer the location up to which the value's lifetime is
> guaranteed to live. An example of where this construct is useful is when one 
> has
> a let binding to a class instance `c` that contains a let field `f`. In that
> case `c`'s lifetime guarantees `f`'s lifetime.
> 
> ## store_strong
> 
> Define a store_strong as follows:
> 
> store_strong %x to %x_ptr : $*C
> 
>=>
> 
> %old_x = load %x_ptr : $*C
> store %new_x to %x_ptr : $*C
> release_value %old_x : $C
> 
> *NOTE* store_strong is defined as a consuming operation. We also provide
> `store_strong [init]` in the case where we know statically that there is no
> previous value in the memory location:
> 
> store_strong %x to [init] %x_ptr : $*C
> 
>=>
> 
> store %new_x to %x_ptr : $*C
> 
> # Implementation
> 
> ## Goals
> 
> Our implementation strategy goals are:
> 
> 1. zero impact on other compiler developers until the feature is fully
>developed. This implies all work will be done behind a flag.
> 2. separation of feature 

Re: [swift-dev] swiftCore dependencies on Foundation

[Joe Groff via swift-dev]

> On Oct 4, 2016, at 10:11 AM, Jordan Rose via swift-dev  
> wrote:
> 
> In HuonW’s recent pull request  we 
> hit an unusual error :
> 
>> 2016-10-03 12:34:08.112 swift[56714:13650955] *** Terminating app due to 
>> uncaught exception 'NSInvalidArgumentException', reason: '*** -length only 
>> defined for abstract class.  Define -[_TtCs19_NSContiguousString length]!'
>> *** First throw call stack:
>> (
>>  0   CoreFoundation  0x7fff9cbe64f2 
>> __exceptionPreprocess + 178
>>  1   libobjc.A.dylib 0x7fff9daaa73c 
>> objc_exception_throw + 48
>>  2   CoreFoundation  0x7fff9cc4d4bd 
>> +[NSException raise:format:] + 205
>>  3   Foundation  0x7fff943e8dbd 
>> NSRequestConcreteImplementation + 229
>>  4   Foundation  0x7fff9442588a -[NSString 
>> length] + 19
>>  5   CoreFoundation  0x7fff9cc2b613 
>> CFStringHashNSString + 51
>>  6   libswiftCore.dylib  0x000114f7ef56 
>> _TTSfq4s___TFSSg9hashValueSi + 118
>>  7   libswiftCore.dylib  0x000114f3b96b 
>> _TTWSSs8HashablesFS_g9hashValueSi + 43
>>  8   libswiftCore.dylib  0x000114e8f0a2 
>> _TFVs24_NativeDictionaryStorage7_bucketfxSi + 34
> 
> We’re not really sure how this could happen, though. _NSContiguousString 
> certainly does implement -length 
> ,
>  and even though there’s an outstanding PR 
>  to change it to a property that 
> shouldn’t cause this kind of issue. (It’s not marked @objc, but it shouldn’t 
> need to be because the superclass is 
> .)
> 
> Anyone know what’s going on here?

I didn't see any obvious reason it would, but since this patch messes with 
IRGen it would be good to double-check that we still emit ObjC class metadata 
with the correct format. This seems like the kind of problem that could arise 
if we ended up generating the method tables incorrectly for some reason.

-Joe

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] swiftCore dependencies on Foundation

[Jordan Rose via swift-dev]

In HuonW’s recent pull request  we 
hit an unusual error :

> 2016-10-03 12:34:08.112 swift[56714:13650955] *** Terminating app due to 
> uncaught exception 'NSInvalidArgumentException', reason: '*** -length only 
> defined for abstract class.  Define -[_TtCs19_NSContiguousString length]!'
> *** First throw call stack:
> (
>   0   CoreFoundation  0x7fff9cbe64f2 
> __exceptionPreprocess + 178
>   1   libobjc.A.dylib 0x7fff9daaa73c 
> objc_exception_throw + 48
>   2   CoreFoundation  0x7fff9cc4d4bd 
> +[NSException raise:format:] + 205
>   3   Foundation  0x7fff943e8dbd 
> NSRequestConcreteImplementation + 229
>   4   Foundation  0x7fff9442588a -[NSString 
> length] + 19
>   5   CoreFoundation  0x7fff9cc2b613 
> CFStringHashNSString + 51
>   6   libswiftCore.dylib  0x000114f7ef56 
> _TTSfq4s___TFSSg9hashValueSi + 118
>   7   libswiftCore.dylib  0x000114f3b96b 
> _TTWSSs8HashablesFS_g9hashValueSi + 43
>   8   libswiftCore.dylib  0x000114e8f0a2 
> _TFVs24_NativeDictionaryStorage7_bucketfxSi + 34

We’re not really sure how this could happen, though. _NSContiguousString 
certainly does implement -length 
,
 and even though there’s an outstanding PR 
 to change it to a property that 
shouldn’t cause this kind of issue. (It’s not marked @objc, but it shouldn’t 
need to be because the superclass is 
.)

Anyone know what’s going on here?

Jordan___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-corelibs-dev] Calendar identifiers

[Pushkar N Kulkarni via swift-corelibs-dev]

Hi Alex, Thanks for your response. This failure doesn't happen with ISO8601 alone. There are half a dozen identifiers that aren't supported. Having said that, I added these identifiers to that if-statement and the calendar initialization did happen:.indian, .islamicTabular, .islamicUmmAlQura, .iso8601, .persian, .republicOfChinaI am not sure if they would cause any other problems thought. Another thing I got curious about: Why is NSCalendar.Identifier.ISO8601 associated with an empty string here (it doesn't really matter, I guess)?https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCalendar.swift#L56Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-alb...@apple.com wrote: -To: Pushkar N Kulkarni/India/IBM@IBMINFrom: Alex Blewitt Sent by: alb...@apple.comDate: 10/04/2016 03:28PMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Calendar identifiersOn 4 Oct 2016, at 10:29, Pushkar N Kulkarni via swift-corelibs-dev  wrote:Hi there, I've hit an obstacle while working on a crash seen in initing a Calendar (https://bugs.swift.org/browse/SR-2551)For the Calendar initialiser "init(identifier: Calendar.Identifier)", the possible values of Calendar.Identifier are listed here. However, we eventually end up calling "_CFCalendarInitWithIdentifier(CFCalendarRef calendar, CFStringRef identifier)" and the latter works only for a specific set of calendar identifiers. See this if statement:   https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/Locale.subproj/CFCalendar.c#L239For other identifier values, we crash (that is SR-2551). On mac, all the identifier values are supported. It seems that the calendar identifier is ultimately encoded as a key-value pair in the locale ID for the calendar.  Can anybody please help me understand the rationale of the if-statement above? I am new to ICU. I did search for justifications but didn't come across convincing. The if statement is canonicalising the reference to the constant e.g. kCFCalendarIdentifierBuddhist. This allows other instances to be passed in but then resolved to the same instance, such that pointer comparisons work for future calls. The same is done for Swift.On macOS, there are additional checks in the CoreFoundation equivalent (such as kCFCalendarIdentifierISO8601) which is why it works on Darwin. However, I don't know if there were specific reasons for excluding the ISO8601 calendar, unless the ICU library doesn't understand it. Testing adding support should be a case of doing something similar to this commit, which re-enabled the Chinese calendar:https://github.com/apple/swift-corelibs-foundation/commit/c1d940dd6099de65f959fd42274cf0e65984efe0Of course building with the 'if' switch enabled may highlight other issues, but on a quick test build it seems that adding the additional if case to the statement results in the ISO8601 calendar being returned. I'll let others explain in more detail if there's some specific subtlety for why it was left out in the first place.Alex

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-dev] Differences between Xcode official toolchains and tagged releases from repository

[Xavier Jurado via swift-dev]

Hello Jordan,

We have filled two bugs against bugs.swift.org to document two crashes
that are only reproducible with our toolchain built from the
swift-2.2.1-RELEASE tag, but that appear fixed in the official
toolchain bundled with Xcode 7.3.1 (7D1014).

Crashers:

https://bugs.swift.org/browse/SR-2844
https://bugs.swift.org/browse/SR-2845

Since using the official toolchain somehow fixes the issues we realize
they are far from critical, but we have reported them in hope of
finding the discrepancies between the official toolchain and the the
tagged releases.

Thanks,
Xavi
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev