Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #11

[Daniel Dunbar via swift-dev]

Cloned off:
   POSIX.popen() sometimes breaks the build

 - Daniel

> On Oct 14, 2016, at 5:25 PM, Doug Coleman via swift-dev  
> wrote:
> 
> > POSIX.popen() sometimes 
> breaks the build
> 
> Looks like it’s still broken?
> 
> Doug
> 
>> On Oct 14, 2016, at 5:17 PM, Doug Coleman > > wrote:
>> 
>> Flaky test code for popen()? I think we saw this before...
>> 
>> 
>> fatal error: 'try!' expression unexpectedly raised an error: 
>> POSIX.ShellError.popen(arguments: ["echo", "foo"], close error: Unknown 
>> error -1): file 
>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/stdlib/public/core/ErrorType.swift,
>>  line 182
>>> On Oct 14, 2016, at 4:48 PM, no-re...@swift.org  
>>> wrote:
>>> 
>>> New issue found!
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#11]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/11/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_10
>>> Date of build:  Fri, 14 Oct 2016 16:22:21 -0700
>>> Build duration: 26 min
>>> Identified problems:
>>> 
>>> Compile Error: This build failed because of a compile error. Below is a 
>>> list of all errors in the build log:
>>> Indication 1 
>>> 
>>> Tests:
>>> 
>>> Name: Swift(linux-x86_64)
>>> Failed: 0 test(s), Passed: 8420 test(s), Total: 8420 test(s)
>>> Name: Swift-Unit
>>> Failed: 0 test(s), Passed: 298 test(s), Total: 298 test(s)
>>> 
>>> Changes
>>> 
>>> Commit 09cbffb3e4ed5c4ef8069d273e2d34309abcd2e4 by Mishal Shah:
>>> Initialize CachedVFile with nullptr
>>> 
>>> edit: include/swift/Basic/SourceManager.h
>>> edit: lib/Basic/SourceLoc.cpp
>> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #11

[Doug Coleman via swift-dev]

 POSIX.popen() sometimes breaks the build

Looks like it’s still broken?

Doug

> On Oct 14, 2016, at 5:17 PM, Doug Coleman  wrote:
> 
> Flaky test code for popen()? I think we saw this before...
> 
> 
> fatal error: 'try!' expression unexpectedly raised an error: 
> POSIX.ShellError.popen(arguments: ["echo", "foo"], close error: Unknown error 
> -1): file 
> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/stdlib/public/core/ErrorType.swift,
>  line 182
>> On Oct 14, 2016, at 4:48 PM, no-re...@swift.org  
>> wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#11]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/11/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Fri, 14 Oct 2016 16:22:21 -0700
>> Build duration:  26 min
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8420 test(s), Total: 8420 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 298 test(s), Total: 298 test(s)
>> 
>> Changes
>> 
>> Commit 09cbffb3e4ed5c4ef8069d273e2d34309abcd2e4 by Mishal Shah:
>> Initialize CachedVFile with nullptr
>> 
>> edit: include/swift/Basic/SourceManager.h
>> edit: lib/Basic/SourceLoc.cpp
> 

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

[swift-dev] Ubuntu 16.10 Bots on ci.swift.org

[mishal_shah via swift-dev]

Ubuntu 16.10 support added to ci.swift.org !  

Ubuntu 16.10 toolchains will be available on swift.org.

Master:
0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) 

0. OSS - Swift Incremental RA - Ubuntu 16.10 - Long Test (master) 

0. OSS - LLDB Incremental - Ubuntu 16.10 (master) 

OSS - Swift Package - Ubuntu 16.10 (master) 


Master-next:
0. OSS - LLDB Incremental - Ubuntu 16.10 (master-next) 

0. OSS - Swift Incremental RA - Ubuntu 16.10 (master-next) 

0. OSS - Swift Incremental RA - Ubuntu 16.10 - Long Test (master-next) 

OSS - Swift Package - Ubuntu 16.10 (master-next) 


Please let me know if you have any questions. 

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #11

[Doug Coleman via swift-dev]

Flaky test code for popen()? I think we saw this before...


fatal error: 'try!' expression unexpectedly raised an error: 
POSIX.ShellError.popen(arguments: ["echo", "foo"], close error: Unknown error 
-1): file 
/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/stdlib/public/core/ErrorType.swift,
 line 182
> On Oct 14, 2016, at 4:48 PM, no-re...@swift.org  
> wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#11]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/11/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Fri, 14 Oct 2016 16:22:21 -0700
> Build duration:   26 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8420 test(s), Total: 8420 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 298 test(s), Total: 298 test(s)
> 
> Changes
> 
> Commit 09cbffb3e4ed5c4ef8069d273e2d34309abcd2e4 by Mishal Shah:
> Initialize CachedVFile with nullptr
> 
> edit: include/swift/Basic/SourceManager.h
> edit: lib/Basic/SourceLoc.cpp

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

Re: [swift-dev] builtin command for invoking a subset of the tests

[Alexis Beingessner via swift-dev]

I've filed 

https://bugs.swift.org/browse/SR-2960
https://bugs.swift.org/browse/SR-2961

(I have no idea of I've done that right)

Sent from my iPhone

> On Oct 14, 2016, at 1:01 PM, Tony Parker  wrote:
> 
> 
>> On Oct 14, 2016, at 9:54 AM, Alexis  wrote:
>> 
>> Oh hey, great! Then perhaps the bigger issue is that this program should be 
>> better highlighted in the developer docs, and possibly even called out in 
>> the build-script docs?
>> 
>> I agree that it needs a bit of TLC, though. Having to specify the build-dir 
>> is a bit disappointing. Any reason it can’t support “use the one that 
>> results from these build-script flags” as the default workflow? (I can 
>> understand wanting to keep build-dir around for special cases)
> 
> Agreed on both points. Probably worth tracking as a starter bug in JIRA. =)
> 
> - Tony
> 
>> 
>>> On Oct 14, 2016, at 11:29 AM, Tony Parker  wrote:
>>> 
>>> Hi Alexis,
>>> 
>>> In fact there is already a script which is closer to what you want, in 
>>> swift/utils/run-test. It could probably use some additional love and 
>>> attention to be a bit more usable (for example, printing out the help if 
>>> you invoke it with no arguments), but I use it all the time.
>>> 
>>> - Tony
>>> 
>>> 
 On Oct 14, 2016, at 8:24 AM, Alexis via swift-dev  
 wrote:
 
 When fixing tests, it’s often useful to be able to run some subset of 
 them, usually based on some pattern. From my searching, the recommended 
 way to do this seems to be to directly invoke `lit.py`. Doing this by hand 
 is tedious, so I use the following script:
 
 
 
 #!/bin/bash
 
 ../llvm/utils/lit/lit.py -sv --param 
 swift_site_config=../build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/test-macosx-x86_64/lit.site.cfg
  "$@"
 
 
 
 But this has the unfortunate downside of hard-coding the compiler to use. 
 It’s also unfortunate for newcomers to the build system, because they need 
 to hunt down this magical invocation, or suffer through running all the 
 tests on every change.
 
 It seems to me that build-script should support this kind of invocation, 
 so that we can say something like:
 
 
 utils/build-script -r —test-only test/stdlib/Dictionary*
 
 
 Thoughts?
 ___
 swift-dev mailing list
 swift-dev@swift.org
 https://lists.swift.org/mailman/listinfo/swift-dev
>>> 
>> 
> 
___
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

[Andrew Trick via swift-dev]

This seems fine to me… at a high level!
-Andy

> On Oct 14, 2016, at 2:44 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
> Attached below is a final version of the proposal. I am going to commit it to 
> the repo if there are no further questions/changes/etc.
> 
>> https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html 
>> 
> Michael
> 
> 
> 
> # Summary
> 
> This document proposes:
> 
> 1. adding the following ownership qualifiers to `load`: `[take]`, `[copy]`,
>`[trivial]`.
> 2. adding the following ownership qualifiers to `store`: `[init]`, `[assign]`,
>`[trivial]`.
> 3. adding the `load_borrow` instruction and the `end_borrow` instruction.
> 3. requiring all `load` and `store` operations to have ownership qualifiers.
> 4. banning the use of `load [trivial]`, `store [trivial]` on memory locations 
> 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. explicitly modeling `load [trivial]`/`store [trivial]` as having `unsafe
>unowned` ownership semantics. This will be enforced via the verifier.
> 3. more aggressive ARC code motion.
> 
> # Definitions
> 
> ## ownership qualified load
> 
> We propose three different ownership qualifiers for load. Define `load 
> [trivial]`
> as:
> 
> %x = load [trivial] %x_ptr : $*Int
> 
>   =>
> 
> %x = load %x_ptr : $*Int
> 
> A `load [trivial]` can not be used to load values of non-trivial type. Define
> `load [copy]` as:
> 
> %x = load [copy] %x_ptr : $*C
> 
>   =>
> 
> %x = load %x_ptr : $*C
> retain_value %x : $C
> 
> Then define `load [take]` as:
> 
> %x = load [take] %x_ptr : $*Builtin.NativeObject
> 
>   =>
> 
> %x = load %x_ptr : $*Builtin.NativeObject
> 
> **NOTE** `load [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.
> 
> ## load_borrow and end_borrow
> 
> Next we provide `load_borrow` and `end_borrow`:
> 
> %x = load_borrow %x_ptr : $*Builtin.NativeObject
> ...
> end_borrow %x, %x_ptr : $*Builtin.NativeObject
> 
>   =>
> 
> %x = load %x_ptr : $*Builtin.NativeObject
> ...
> endLifetime %x : $Builtin.NativeObject
> fixLifetime %x_ptr : $*Builtin.NativeObject
> 
> `load [borrow]` implies that in the region between the `load` and the
> `end_borrow`, the loaded object must semantically remain alive. The 
> `end_borrow`
> communicates to the optimizer:
> 
> 1. that the value in `%x_ptr` should not be destroyed before endBorrow.
> 2. uses of `%x` should not be sunk past endBorrow since `%x` is only a shallow
>copy of the value in `%x_ptr` and past that point `%x_ptr` may not remain
>alive.
> 
> 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 meaning that returning `f` over the function call
> boundary is safe.
> 
> *NOTE* since the SILOwnershipModelEliminator will not process these
> instructions, endLifetime is just a strawman instruction that will not be
> implemented. In practice though, IRGen will need to create a suitable barrier 
> to
> ensure that LLVM does not move any uses of `%x` past the `fixLifetime`
> instruction of `%x_ptr` once we begin creating such instructions as a result 
> of
> ARC optimization.
> 
> ## ownership qualified store
> 
> First define a `store [trivial]` as:
> 
> store %x to [trivial] %x_ptr : $*Int
> 
>   =>
> 
> store %x to %x_ptr : $*Int
> 
> The verifier will prevent this instruction from being used on types with
> non-trivial ownership. Define a `store [assign]` as follows:
> 
> store %x to [assign] %x_ptr : $*C
> 
>=>
> 
> %old_x = load %x_ptr : $*C
> store %new_x to %x_ptr : $*C
> release_value %old_x : $C
> 
> *NOTE* `store` is defined as a consuming operation. We also provide
> `store [init]` in the case where we know statically that there is no
> previous value in the memory location:
> 
> store %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 implementation from updating passes.
> 
> Goal 2 will be implemented via a pass that transforms ownership qualified
> `load`/`store` instructions into unqualified `load`/`store` right after 
> SILGen.
> 
> ## Plan
> 
> We begin by adding initial 

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #11

[mishal_shah via swift-dev]

Hi, 

Can someone please look at this error? 

Test Case 'ShellTests.testPopen' started at 23:47:15.353
fatal error: 'try!' expression unexpectedly raised an error: 
POSIX.ShellError.popen(arguments: ["echo", "foo"], close error: Unknown error 
-1): file 
/home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/stdlib/public/core/ErrorType.swift,
 line 182
Current stack trace:
0libswiftCore.so0x7ff1fcb13350 swift_reportError + 
117
1libswiftCore.so0x7ff1fcb26fe0 
_swift_stdlib_reportFatalErrorInFile + 106
2libswiftCore.so0x7ff1fc90400f  + 
1200143
3libswiftCore.so0x7ff1fcac7af0  + 
3050224
4libswiftCore.so0x7ff1fc9035b6  + 
1197494
5libswiftCore.so0x7ff1fcacbe10  + 
3067408
6libswiftCore.so0x7ff1fc903d8e  + 
1199502
7libswiftCore.so0x7ff1fca8c019  + 
2805785
8libswiftCore.so0x7ff1fc9035b6  + 
1197494
9libswiftCore.so0x7ff1fca3da00 specialized 
_assertionFailed(StaticString, String, StaticString, UInt, flags : UInt32) -> 
Never + 144
10   libswiftCore.so0x7ff1fc930dc0  + 
1383872
11   SwiftPMPackageTests.xctest 0x004234fe  + 
144638
12   SwiftPMPackageTests.xctest 0x004215e7  + 
136679
13   SwiftPMPackageTests.xctest 0x00423681  + 
145025
14   libXCTest.so   0x7ff1fcd597c1  + 
133057
15   libXCTest.so   0x7ff1fcd59c7f  + 
134271
16   libXCTest.so   0x7ff1fcd596e0 XCTAssertEqual (@autoclosure () throws -> A, @autoclosure () throws -> A, 
@autoclosure () -> String, file : StaticString, line : UInt) -> () + 89
17   SwiftPMPackageTests.xctest 0x004233ed  + 
144365
18   SwiftPMPackageTests.xctest 0x00424e1a  + 
151066
19   SwiftPMPackageTests.xctest 0x00424501  + 
148737
20   SwiftPMPackageTests.xctest 0x00424db1  + 
150961
21   libXCTest.so   0x7ff1fcd8810b  + 
323851
22   libXCTest.so   0x7ff1fcd581d3  + 
127443
23   libXCTest.so   0x7ff1fcd880c0  + 
323776
24   libXCTest.so   0x7ff1fcd87e70  + 
323184
25   libXCTest.so   0x7ff1fcd578a0 
XCTestCase.invokeTest() -> () + 111
26   libXCTest.so   0x7ff1fcd77e20 specialized 
XCTestCase.perform(XCTestRun) -> () + 313
27   libXCTest.so   0x7ff1fcd577d0 
XCTestCase.perform(XCTestRun) -> () + 14
28   libXCTest.so   0x7ff1fcd52960 XCTest.run() -> () + 
516
29   libXCTest.so   0x7ff1fcd78be0 specialized 
XCTestSuite.perform(XCTestRun) -> () + 886
30   libXCTest.so   0x7ff1fcd78be0 specialized 
XCTestSuite.perform(XCTestRun) -> () + 1975
31   libXCTest.so   0x7ff1fcd78be0 specialized 
XCTestSuite.perform(XCTestRun) -> () + 1975
32   libXCTest.so   0x7ff1fcd61930 
XCTMain([(testCaseClass : XCTestCase.Type, allTests : [(String, (XCTestCase) 
throws -> ())])]) -> Never + 5053
33   SwiftPMPackageTests.xctest 0x0041c422  + 
115746
34   libc.so.6  0x7ff1fa983300 __libc_start_main + 
241
35   SwiftPMPackageTests.xctest 0x0041c03a  + 
114746

--- bootstrap: error: tests failed with exit status 1

Thanks, 
Mishal Shah
> On Oct 14, 2016, at 4:48 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#11]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/11/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Fri, 14 Oct 2016 16:22:21 -0700
> Build duration:   26 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Tests: 
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8420 test(s), Total: 8420 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 298 test(s), Total: 298 test(s)
> 
> Changes
> 
> Commit 09cbffb3e4ed5c4ef8069d273e2d34309abcd2e4 by Mishal Shah:
> Initialize CachedVFile with nullptr
> 
> edit: include/swift/Basic/SourceManager.h
> edit: lib/Basic/SourceLoc.cpp

___
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

[Michael Gottesman via swift-dev]

Attached below is a final version of the proposal. I am going to commit it to 
the repo if there are no further questions/changes/etc.

> https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html 
> 
Michael



# Summary

This document proposes:

1. adding the following ownership qualifiers to `load`: `[take]`, `[copy]`,
   `[trivial]`.
2. adding the following ownership qualifiers to `store`: `[init]`, `[assign]`,
   `[trivial]`.
3. adding the `load_borrow` instruction and the `end_borrow` instruction.
3. requiring all `load` and `store` operations to have ownership qualifiers.
4. banning the use of `load [trivial]`, `store [trivial]` on memory locations 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. explicitly modeling `load [trivial]`/`store [trivial]` as having `unsafe
   unowned` ownership semantics. This will be enforced via the verifier.
3. more aggressive ARC code motion.

# Definitions

## ownership qualified load

We propose three different ownership qualifiers for load. Define `load 
[trivial]`
as:

%x = load [trivial] %x_ptr : $*Int

  =>

%x = load %x_ptr : $*Int

A `load [trivial]` can not be used to load values of non-trivial type. Define
`load [copy]` as:

%x = load [copy] %x_ptr : $*C

  =>

%x = load %x_ptr : $*C
retain_value %x : $C

Then define `load [take]` as:

%x = load [take] %x_ptr : $*Builtin.NativeObject

  =>

%x = load %x_ptr : $*Builtin.NativeObject

**NOTE** `load [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.

## load_borrow and end_borrow

Next we provide `load_borrow` and `end_borrow`:

%x = load_borrow %x_ptr : $*Builtin.NativeObject
...
end_borrow %x, %x_ptr : $*Builtin.NativeObject

  =>

%x = load %x_ptr : $*Builtin.NativeObject
...
endLifetime %x : $Builtin.NativeObject
fixLifetime %x_ptr : $*Builtin.NativeObject

`load [borrow]` implies that in the region between the `load` and the
`end_borrow`, the loaded object must semantically remain alive. The `end_borrow`
communicates to the optimizer:

1. that the value in `%x_ptr` should not be destroyed before endBorrow.
2. uses of `%x` should not be sunk past endBorrow since `%x` is only a shallow
   copy of the value in `%x_ptr` and past that point `%x_ptr` may not remain
   alive.

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 meaning that returning `f` over the function call
boundary is safe.

*NOTE* since the SILOwnershipModelEliminator will not process these
instructions, endLifetime is just a strawman instruction that will not be
implemented. In practice though, IRGen will need to create a suitable barrier to
ensure that LLVM does not move any uses of `%x` past the `fixLifetime`
instruction of `%x_ptr` once we begin creating such instructions as a result of
ARC optimization.

## ownership qualified store

First define a `store [trivial]` as:

store %x to [trivial] %x_ptr : $*Int

  =>

store %x to %x_ptr : $*Int

The verifier will prevent this instruction from being used on types with
non-trivial ownership. Define a `store [assign]` as follows:

store %x to [assign] %x_ptr : $*C

   =>

%old_x = load %x_ptr : $*C
store %new_x to %x_ptr : $*C
release_value %old_x : $C

*NOTE* `store` is defined as a consuming operation. We also provide
`store [init]` in the case where we know statically that there is no
previous value in the memory location:

store %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 implementation from updating passes.

Goal 2 will be implemented via a pass that transforms ownership qualified
`load`/`store` instructions into unqualified `load`/`store` right after SILGen.

## Plan

We begin by adding initial infrastructure for our development. This means:

1. Adding to SILOptions a disabled by default flag called
 "EnableSILOwnershipModel". This flag will be set by a false by default frontend
 option called "-enable-sil-ownership-mode".

2. Bots will be brought up to test the compiler with
   "-enable-sil-ownership-model" set to true. The specific bots are:

   * RA-OSX+simulators
   * RA-Device
   * RA-Linux.

   The bots will run once a day until the feature is close to 

Re: [swift-dev] Dictionary Collision Resolution Guarantees

[Dave Abrahams via swift-dev]

on Fri Oct 14 2016, Ole Begemann  wrote:

> On 14/10/2016 02:46, Dave Abrahams wrote:
>
>>> OK cool, is there any reason it’s even written down? I don’t see any code
>>> that’s obviously relying on it. (seems fine to delete it?)
>>
>> It's written down because we've never formalized our index invalidation
>> rules.  I didn't realize that this comment was related to index
>> invalidation.  The guarantee mentioned is one we might want to give, at
>> least under some circumstances.  We'll have to think about that more
>> carefully.  In any case, it's not time to delete it yet.
>
> For what it's worth, this rule is also explicitly mentioned in
> docs/IndexInvalidation.rst
> (https://github.com/apple/swift/blob/master/docs/IndexInvalidation.rst):
>
> "Insertion into a Dictionary invalidates indexes only on a rehash. If
> a Dictionary has enough free buckets (guaranteed by calling an
> initializer or reserving space), then inserting elements does not
> invalidate indexes.
>
> Note: unlike C++'s std::unordered_map, removing elements from a
> Dictionary invalidates indexes."
>
> (I realize the stuff in /docs is not necessarily official
> documentation (right?), I just wanted to mention it.)

Thanks for pointing that out; that's important.

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

Re: [swift-dev] builtin command for invoking a subset of the tests

[Tony Parker via swift-dev]

Hi Alexis,

In fact there is already a script which is closer to what you want, in 
swift/utils/run-test. It could probably use some additional love and attention 
to be a bit more usable (for example, printing out the help if you invoke it 
with no arguments), but I use it all the time.

- Tony


> On Oct 14, 2016, at 8:24 AM, Alexis via swift-dev  wrote:
> 
> When fixing tests, it’s often useful to be able to run some subset of them, 
> usually based on some pattern. From my searching, the recommended way to do 
> this seems to be to directly invoke `lit.py`. Doing this by hand is tedious, 
> so I use the following script:
> 
> 
> 
>#!/bin/bash
> 
>../llvm/utils/lit/lit.py -sv --param 
> swift_site_config=../build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/test-macosx-x86_64/lit.site.cfg
>  "$@"
> 
> 
> 
> But this has the unfortunate downside of hard-coding the compiler to use. 
> It’s also unfortunate for newcomers to the build system, because they need to 
> hunt down this magical invocation, or suffer through running all the tests on 
> every change.
> 
> It seems to me that build-script should support this kind of invocation, so 
> that we can say something like:
> 
> 
>utils/build-script -r —test-only test/stdlib/Dictionary*
> 
> 
> Thoughts?
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

[swift-dev] builtin command for invoking a subset of the tests

[Alexis via swift-dev]

When fixing tests, it’s often useful to be able to run some subset of them, 
usually based on some pattern. From my searching, the recommended way to do 
this seems to be to directly invoke `lit.py`. Doing this by hand is tedious, so 
I use the following script:



#!/bin/bash

../llvm/utils/lit/lit.py -sv --param 
swift_site_config=../build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/test-macosx-x86_64/lit.site.cfg
 "$@"



But this has the unfortunate downside of hard-coding the compiler to use. It’s 
also unfortunate for newcomers to the build system, because they need to hunt 
down this magical invocation, or suffer through running all the tests on every 
change.

It seems to me that build-script should support this kind of invocation, so 
that we can say something like:


utils/build-script -r —test-only test/stdlib/Dictionary*


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