Re: [swift-dev] Changing ELF layout

[Saleem Abdulrasool via swift-dev]

On Mon, Sep 18, 2017 at 4:07 PM, Joe Groff  wrote:

>
>
> On Sep 18, 2017, at 3:31 PM, Saleem Abdulrasool via swift-dev <
> swift-dev@swift.org> wrote:
>
>
> On Mon, Sep 18, 2017 at 9:36 AM John McCall  wrote:
>
>> On Sep 17, 2017, at 10:15 AM, Saleem Abdulrasool 
>> wrote:
>>
>> On Sat, Sep 16, 2017 at 6:19 PM, John McCall  wrote:
>>
>>> > On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev <
>>> swift-dev@swift.org> wrote:
>>> > Hello,
>>> >
>>> > I'd like to propose that we change the locations that we use to store
>>> the type metadata, protocol conformances, type references, reflection
>>> strings, field metadata, and associated types.
>>> >
>>> > I think that it is possible to simplify the design for the linker
>>> tables by changing section names and relying on the linker to perform the
>>> work necessary to generate the tables so that they can be walked later.
>>> >
>>> > Switching sections would mean that we would lose interoperability with
>>> previously built libraries.  Given that there is ABI stability work going
>>> on for at least the Darwin target, I figure that this would be the best
>>> time to do this.
>>> >
>>> > Would this be acceptable?  Is compatibility something that we need to
>>> worry about?
>>>
>>> Compatibility is not something that we're currently promising.  I think
>>> this is a fine time to be working on this problem.
>>>
>>> It's not clear from your proposal whether you're just proposing changing
>>> sections or whether you're interested in more invasive changes to metadata
>>> emission.  Can you be more specific.
>>
>>
>> Certainly.
>>
>> Right now, we have two special object files which must be included in a
>> certain order to ensure that the sections that I mentioned earlier are
>> bounded and grouped.  However, this is unneessary.  As long as the section
>> name is a valid C identifier, the linker will group and bound the sections
>> with special variables that it will synthesize
>> (__{start,stop}_[SectionName]).  This will allow us to replace the two
>> file approach with a single file approach.  Furthermore, it will allow the
>> file to be injected anywhere (it drops the need for the files to appear in
>> a specific order).  Finally, it simplifies the logic so that we can write
>> the entire thing in C rather than having to roll the begin/end content in
>> assembly.
>>
>>
>> Yes, if that's the case, that would be massively useful.
>>
>> The runtime needs to be able to find these bounds in an arbitrary image,
>> since there may be multiple images in the program containing Swift code.
>> Are those symbols available dynamically even if it they aren't used
>> statically?
>>
>
> It should be possible to preserve the symbols.  In general, it is possible
> to dead strip symbols.  So having the object that needs to be injected
> reference them is sufficient to ensure that they aren't dead stripped.
> After that, they can be dynamically looked up even if they aren't
> statically used.
>
> I'll try to get to this change soon!
>
>
> The symbols would not only have to not be stripped but also be exported
> with protected or default visibility in order for dlsym to find them
> normally. Is it possible to get the linker to export these implicit symbols
> with protected visibility? If not, we might still need an asm stub to
> define visible symbols as aliases for the implicit section symbols. That
> stub could at least be order-independent and portable, which would be an
> improvement over what we have now.
>

The default is default visibility, which IMO is not really what we want.
Ideally, we want protected visibility.  Now, this is possible to, but, the
code for is every so slightly distasteful.

```
__attribute__((__section__("section"))) const int i = 0;
__attribute__((__visibility__("protected"))) extern void *__start_section;
__attribute__((__visibility__("protected"))) extern void *__stop_section;
__UINTPTR_TYPE__ get_section_size(void) { return __stop_section -
__start_section; }
```

The thing is that we need the local function (in this case,
`get_section_size`) to both preserve the symbols as well as to ensure that
the symbols receive the proper visibility.  In the worst case, we would
need a structure that is preserved to aid in keeping the reference to the
symbols.

-Joe
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
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.04 (master) #596

[Saleem Abdulrasool via swift-dev]

PR#11994

On Mon, Sep 18, 2017 at 7:13 PM, Saleem Abdulrasool via swift-dev <
swift-dev@swift.org> wrote:

> Ugh, I think I see what the issue is.  The build-script-impl wrapper is
> pretty intricate and I missed the conditional check since it was pretty
> similar to the one near it.  I guess the test for the original change didnt
> notice it due to caching effects.  I'll have a fix up for this momentarily.
>
> On Mon, Sep 18, 2017 at 6:59 PM, Saleem Abdulrasool via swift-dev <
> swift-dev@swift.org> wrote:
>
>> Yeah, Im looking into this.  That is a really weird error.  It seems like
>> it would be related to the the switch to CMake for libdispatch.
>>
>> On Mon, Sep 18, 2017 at 6:34 PM, Vedant Kumar via swift-dev <
>> swift-dev@swift.org> wrote:
>>
>>> I don't think I have changed this or control it:
>>>
>>> --install-destdir is required to install products.
>>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>>>  fatal error: command terminated with a non-zero exit status 1, aborting
>>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>>>  fatal error: command terminated with a non-zero exit status 1, aborting
>>>
>>>
>>> vedant
>>>
>>> On Sep 18, 2017, at 6:32 PM, no-re...@swift.org wrote:
>>>
>>> New issue found![FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04
>>> [#596]
>>> Build URL: https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubun
>>> tu-16_04/596/
>>> Project: oss-swift-incremental-RA-linux-ubuntu-16_04
>>> Date of build: Mon, 18 Sep 2017 19:25:52 -0500
>>> Build duration: 1 hr 7 minTests:
>>> Name: *Swift(linux-x86_64)*
>>> Failed: 0 test(s), Passed: 9899 test(s), Total: 9899 test(s)
>>> Name: *Swift-Unit*
>>> Failed: 0 test(s), Passed: 461 test(s), Total: 461 test(s)
>>>
>>> Changes
>>>
>>>- Commit *7e0311ad2cf4f688518aed84a665b6c8a50eaefc* by *vsk:*
>>>
>>>[Coverage] Use gap regions to select better line exec counts
>>>- *edit*: include/llvm/ProfileData/InstrProfData.inc
>>>   - *edit*: tools/llvm-cov/SourceCoverageViewText.cpp
>>>   - *edit*: lib/ProfileData/Coverage/CoverageMappingReader.cpp
>>>   - *edit*: lib/ProfileData/Coverage/CoverageMapping.cpp
>>>   - *edit*: docs/CoverageMappingFormat.rst
>>>   - *edit*: tools/llvm-cov/SourceCoverageViewHTML.cpp
>>>   - *edit*: tools/llvm-cov/SourceCoverageView.cpp
>>>   - *edit*: include/llvm/ProfileData/Coverage/CoverageMapping.h
>>>   - *edit*: test/tools/llvm-cov/deferred-region.cpp
>>>   - *edit*: lib/ProfileData/Coverage/CoverageMappingWriter.cpp
>>>   - *edit*: test/tools/llvm-cov/Inputs/deferred-regions.covmapping
>>>
>>>- Commit *9a8caaf5b6cd207d61e0867ea46650d45a3e5adf* by *vsk:*
>>>
>>>[profile] Update InstrProfData.inc
>>>- *edit*: lib/profile/InstrProfData.inc
>>>
>>>- Commit *223e2eacb73b51efd6284bfb15ac1ef9b596a2e6* by *vsk:*
>>>
>>>[cmake] Make it possible to build and test profile without sanitizers
>>>- *edit*: lib/CMakeLists.txt
>>>   - *edit*: test/CMakeLists.txt
>>>
>>>
>>>
>>> ___
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>>
>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
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.04 (master) #596

[Saleem Abdulrasool via swift-dev]

Ugh, I think I see what the issue is.  The build-script-impl wrapper is
pretty intricate and I missed the conditional check since it was pretty
similar to the one near it.  I guess the test for the original change didnt
notice it due to caching effects.  I'll have a fix up for this momentarily.

On Mon, Sep 18, 2017 at 6:59 PM, Saleem Abdulrasool via swift-dev <
swift-dev@swift.org> wrote:

> Yeah, Im looking into this.  That is a really weird error.  It seems like
> it would be related to the the switch to CMake for libdispatch.
>
> On Mon, Sep 18, 2017 at 6:34 PM, Vedant Kumar via swift-dev <
> swift-dev@swift.org> wrote:
>
>> I don't think I have changed this or control it:
>>
>> --install-destdir is required to install products.
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>>  fatal error: command terminated with a non-zero exit status 1, aborting
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>>  fatal error: command terminated with a non-zero exit status 1, aborting
>>
>>
>> vedant
>>
>> On Sep 18, 2017, at 6:32 PM, no-re...@swift.org wrote:
>>
>> New issue found![FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04
>> [#596]
>> Build URL: https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubun
>> tu-16_04/596/
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_04
>> Date of build: Mon, 18 Sep 2017 19:25:52 -0500
>> Build duration: 1 hr 7 minTests:
>> Name: *Swift(linux-x86_64)*
>> Failed: 0 test(s), Passed: 9899 test(s), Total: 9899 test(s)
>> Name: *Swift-Unit*
>> Failed: 0 test(s), Passed: 461 test(s), Total: 461 test(s)
>>
>> Changes
>>
>>- Commit *7e0311ad2cf4f688518aed84a665b6c8a50eaefc* by *vsk:*
>>
>>[Coverage] Use gap regions to select better line exec counts
>>- *edit*: include/llvm/ProfileData/InstrProfData.inc
>>   - *edit*: tools/llvm-cov/SourceCoverageViewText.cpp
>>   - *edit*: lib/ProfileData/Coverage/CoverageMappingReader.cpp
>>   - *edit*: lib/ProfileData/Coverage/CoverageMapping.cpp
>>   - *edit*: docs/CoverageMappingFormat.rst
>>   - *edit*: tools/llvm-cov/SourceCoverageViewHTML.cpp
>>   - *edit*: tools/llvm-cov/SourceCoverageView.cpp
>>   - *edit*: include/llvm/ProfileData/Coverage/CoverageMapping.h
>>   - *edit*: test/tools/llvm-cov/deferred-region.cpp
>>   - *edit*: lib/ProfileData/Coverage/CoverageMappingWriter.cpp
>>   - *edit*: test/tools/llvm-cov/Inputs/deferred-regions.covmapping
>>
>>- Commit *9a8caaf5b6cd207d61e0867ea46650d45a3e5adf* by *vsk:*
>>
>>[profile] Update InstrProfData.inc
>>- *edit*: lib/profile/InstrProfData.inc
>>
>>- Commit *223e2eacb73b51efd6284bfb15ac1ef9b596a2e6* by *vsk:*
>>
>>[cmake] Make it possible to build and test profile without sanitizers
>>- *edit*: lib/CMakeLists.txt
>>   - *edit*: test/CMakeLists.txt
>>
>>
>>
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
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.04 (master) #596

[Saleem Abdulrasool via swift-dev]

Yeah, Im looking into this.  That is a really weird error.  It seems like
it would be related to the the switch to CMake for libdispatch.

On Mon, Sep 18, 2017 at 6:34 PM, Vedant Kumar via swift-dev <
swift-dev@swift.org> wrote:

> I don't think I have changed this or control it:
>
> --install-destdir is required to install products.
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 1, aborting
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 1, aborting
>
>
> vedant
>
> On Sep 18, 2017, at 6:32 PM, no-re...@swift.org wrote:
>
> New issue found![FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04
> [#596]
> Build URL: https://ci.swift.org/job/oss-swift-incremental-RA-linux-
> ubuntu-16_04/596/
> Project: oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build: Mon, 18 Sep 2017 19:25:52 -0500
> Build duration: 1 hr 7 minTests:
> Name: *Swift(linux-x86_64)*
> Failed: 0 test(s), Passed: 9899 test(s), Total: 9899 test(s)
> Name: *Swift-Unit*
> Failed: 0 test(s), Passed: 461 test(s), Total: 461 test(s)
>
> Changes
>
>- Commit *7e0311ad2cf4f688518aed84a665b6c8a50eaefc* by *vsk:*
>
>[Coverage] Use gap regions to select better line exec counts
>- *edit*: include/llvm/ProfileData/InstrProfData.inc
>   - *edit*: tools/llvm-cov/SourceCoverageViewText.cpp
>   - *edit*: lib/ProfileData/Coverage/CoverageMappingReader.cpp
>   - *edit*: lib/ProfileData/Coverage/CoverageMapping.cpp
>   - *edit*: docs/CoverageMappingFormat.rst
>   - *edit*: tools/llvm-cov/SourceCoverageViewHTML.cpp
>   - *edit*: tools/llvm-cov/SourceCoverageView.cpp
>   - *edit*: include/llvm/ProfileData/Coverage/CoverageMapping.h
>   - *edit*: test/tools/llvm-cov/deferred-region.cpp
>   - *edit*: lib/ProfileData/Coverage/CoverageMappingWriter.cpp
>   - *edit*: test/tools/llvm-cov/Inputs/deferred-regions.covmapping
>
>- Commit *9a8caaf5b6cd207d61e0867ea46650d45a3e5adf* by *vsk:*
>
>[profile] Update InstrProfData.inc
>- *edit*: lib/profile/InstrProfData.inc
>
>- Commit *223e2eacb73b51efd6284bfb15ac1ef9b596a2e6* by *vsk:*
>
>[cmake] Make it possible to build and test profile without sanitizers
>- *edit*: lib/CMakeLists.txt
>   - *edit*: test/CMakeLists.txt
>
>
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
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.04 (master) #596

[Vedant Kumar via swift-dev]

I don't think I have changed this or control it:
--install-destdir is required to install products.
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
 fatal error: command terminated with a non-zero exit status 1, aborting
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
 fatal error: command terminated with a non-zero exit status 1, aborting

vedant

> On Sep 18, 2017, at 6:32 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#596]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/596/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Mon, 18 Sep 2017 19:25:52 -0500
> Build duration:   1 hr 7 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9899 test(s), Total: 9899 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 461 test(s), Total: 461 test(s)
> 
> Changes
> 
> Commit 7e0311ad2cf4f688518aed84a665b6c8a50eaefc by vsk:
> [Coverage] Use gap regions to select better line exec counts
> 
> edit: include/llvm/ProfileData/InstrProfData.inc
> edit: tools/llvm-cov/SourceCoverageViewText.cpp
> edit: lib/ProfileData/Coverage/CoverageMappingReader.cpp
> edit: lib/ProfileData/Coverage/CoverageMapping.cpp
> edit: docs/CoverageMappingFormat.rst
> edit: tools/llvm-cov/SourceCoverageViewHTML.cpp
> edit: tools/llvm-cov/SourceCoverageView.cpp
> edit: include/llvm/ProfileData/Coverage/CoverageMapping.h
> edit: test/tools/llvm-cov/deferred-region.cpp
> edit: lib/ProfileData/Coverage/CoverageMappingWriter.cpp
> edit: test/tools/llvm-cov/Inputs/deferred-regions.covmapping
> 
> Commit 9a8caaf5b6cd207d61e0867ea46650d45a3e5adf by vsk:
> [profile] Update InstrProfData.inc
> 
> edit: lib/profile/InstrProfData.inc
> 
> Commit 223e2eacb73b51efd6284bfb15ac1ef9b596a2e6 by vsk:
> [cmake] Make it possible to build and test profile without sanitizers
> 
> edit: lib/CMakeLists.txt
> edit: test/CMakeLists.txt

___
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.04 (master) #595

[Vedant Kumar via swift-dev]

The sync'd llvm change did not make it into this build.

vedant

> On Sep 18, 2017, at 5:24 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#595]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/595/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Mon, 18 Sep 2017 19:08:14 -0500
> Build duration:   17 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 
> 
> Changes
> 
> Commit ec1e051a3670dcf83f25f6dd027480fbf290146e by rlevenstein:
> Add runtime library support for tracking the invocations of runtime
> 
> add: stdlib/public/runtime/RuntimeInvocationsTracking.cpp
> edit: stdlib/public/runtime/CMakeLists.txt
> edit: stdlib/public/runtime/HeapObject.cpp
> add: stdlib/public/runtime/RuntimeInvocationsTracking.h
> 
> Commit a590e4902e20b44ce8733b4ee5ec8f2e0c3cfa39 by rlevenstein:
> Add experimental Swift standard library support for tracking the
> 
> edit: stdlib/public/core/GroupInfo.json
> add: stdlib/public/core/RuntimeFunctionCounters.swift
> edit: stdlib/public/core/CMakeLists.txt
> 
> Commit 4b2c6c017e1554deb25ea715873dcebd26a7a3aa by rlevenstein:
> Add a test for testing the runtime function counters functionality
> 
> add: test/stdlib/test_runtime_function_counters.swift
> 
> Commit a4d5cad3a5da40b4b697e90d2dcd5cc7f14fe42a by rlevenstein:
> Fix creation of UnsafeRawPointer for found references
> 
> edit: stdlib/public/core/RuntimeFunctionCounters.swift
> 
> Commit 3392b765ea9f74b562d72eac0cffa238a65e78be by rlevenstein:
> Provide runtime function counters for object allocation, deallocation
> 
> edit: test/stdlib/test_runtime_function_counters.swift
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.h
> edit: stdlib/public/runtime/HeapObject.cpp
> 
> Commit 045dc3495566980040215dd581101cad6d9bf628 by rlevenstein:
> Address review comments related to the Swift standard library part of
> 
> edit: stdlib/public/core/RuntimeFunctionCounters.swift
> edit: test/stdlib/test_runtime_function_counters.swift
> 
> Commit 1996d5fb645797691685f44b863a6f99fdacab2b by rlevenstein:
> Address review comments.
> 
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.cpp
> add: stdlib/public/runtime/RuntimeInvocationsTracking.def
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.h
> 
> Commit 2012451eb1edd1f02e1a16661e9f4ac0d31dbc58 by rlevenstein:
> Fix a macro-definition
> 
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.h
> 
> Commit 8027fa2b0a1bc4574151b6487234ac553eaf3be8 by rlevenstein:
> The test needs the standard library (the runtime library part of it)
> 
> edit: test/stdlib/test_runtime_function_counters.swift
> 
> Commit 460de35b824c3ee26e868b51e8d8aacbd07de41f by rlevenstein:
> Expose runtime APIs for runtime function counters in such a way that
> 
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.h
> 
> Commit 7aa8d6f2b6e5e228f96daba42db1d6d50d68aec5 by rlevenstein:
> Warn if FUNCTION_TO_TRACK is not defined
> 
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.def
> 
> Commit d8c5238449b45f69598c9cc5406310c757194ce9 by rlevenstein:
> Move FUNCTION_TO_TRACK definitions closer to the includes of
> 
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.cpp
> 
> Commit acf94f94eca4ef0383e461548ddb55e945c3332d by lance_parker:
> Add -Onone to all the _Debug tests
> 
> edit: test/stdlib/StringTraps.swift
> edit: test/stdlib/RangeTraps.swift
> edit: validation-test/stdlib/FloatingPointConversion.swift.gyb
> edit: test/stdlib/DictionaryTraps.swift
> edit: validation-test/stdlib/ArrayTraps.swift.gyb
> edit: validation-test/stdlib/FixedPointConversion.swift.gyb
> edit: validation-test/stdlib/ArrayTrapsObjC.swift.gyb
> edit: test/stdlib/IntervalTraps.swift
> edit: validation-test/stdlib/DictionaryTrapsObjC.swift
> edit: test/stdlib/SetTrapsObjC.swift
> edit: test/stdlib/CharacterTraps.swift
> edit: test/stdlib/SetTraps.swift
> edit: validation-test/stdlib/FixedPointArithmeticTraps.swift.gyb
> edit: validation-test/stdlib/Assert.swift
> 
> Commit 51bb830763190c70bc1316d9a0b60614550b8afb by rlevenstein:
> #include should be on the next line after #define
> 
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.h
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.cpp
> 
> Commit acff3212b5ccca477c223b2256f0dc321486cf38 by rlevenstein:
> Add a comment explaining why the file needs to be compiled even in
> 
> edit: stdlib/public/runtime/RuntimeInvocationsTracking.cpp
> 
> Commit 8dfdcd9a617ed07c2c79a1995c872dd5175143ac by rlevenstein:
> Check that the runtime counters APIs are available even in no-asserts
> 
> 

Re: [swift-dev] Changing ELF layout

[Joe Groff via swift-dev]

> On Sep 18, 2017, at 3:31 PM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> 
> On Mon, Sep 18, 2017 at 9:36 AM John McCall  > wrote:
>> On Sep 17, 2017, at 10:15 AM, Saleem Abdulrasool > > wrote:
>> 
>> On Sat, Sep 16, 2017 at 6:19 PM, John McCall > > wrote:
>> > On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev 
>> > > wrote:
>> > Hello,
>> >
>> > I'd like to propose that we change the locations that we use to store the 
>> > type metadata, protocol conformances, type references, reflection strings, 
>> > field metadata, and associated types.
>> >
>> > I think that it is possible to simplify the design for the linker tables 
>> > by changing section names and relying on the linker to perform the work 
>> > necessary to generate the tables so that they can be walked later.
>> >
>> > Switching sections would mean that we would lose interoperability with 
>> > previously built libraries.  Given that there is ABI stability work going 
>> > on for at least the Darwin target, I figure that this would be the best 
>> > time to do this.
>> >
>> > Would this be acceptable?  Is compatibility something that we need to 
>> > worry about?
>> 
>> Compatibility is not something that we're currently promising.  I think this 
>> is a fine time to be working on this problem.
>> 
>> It's not clear from your proposal whether you're just proposing changing 
>> sections or whether you're interested in more invasive changes to metadata 
>> emission.  Can you be more specific.
>> 
>> Certainly.
>> 
>> Right now, we have two special object files which must be included in a 
>> certain order to ensure that the sections that I mentioned earlier are 
>> bounded and grouped.  However, this is unneessary.  As long as the section 
>> name is a valid C identifier, the linker will group and bound the sections 
>> with special variables that it will synthesize 
>> (__{start,stop}_[SectionName]).  This will allow us to replace the two file 
>> approach with a single file approach.  Furthermore, it will allow the file 
>> to be injected anywhere (it drops the need for the files to appear in a 
>> specific order).  Finally, it simplifies the logic so that we can write the 
>> entire thing in C rather than having to roll the begin/end content in 
>> assembly.
> 
> Yes, if that's the case, that would be massively useful.
> 
> The runtime needs to be able to find these bounds in an arbitrary image, 
> since there may be multiple images in the program containing Swift code.  Are 
> those symbols available dynamically even if it they aren't used statically?
> 
> It should be possible to preserve the symbols.  In general, it is possible to 
> dead strip symbols.  So having the object that needs to be injected reference 
> them is sufficient to ensure that they aren't dead stripped.  After that, 
> they can be dynamically looked up even if they aren't statically used.
> 
> I'll try to get to this change soon!

The symbols would not only have to not be stripped but also be exported with 
protected or default visibility in order for dlsym to find them normally. Is it 
possible to get the linker to export these implicit symbols with protected 
visibility? If not, we might still need an asm stub to define visible symbols 
as aliases for the implicit section symbols. That stub could at least be 
order-independent and portable, which would be an improvement over what we have 
now.

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

[swift-dev] CI outage tomorrow

[Nicole Jacque via swift-dev]

Hi All-

Tomorrow, we will be temporarily bringing down the CI, starting around 1 PM, 
California time, in order to upgrade Xcode and SDKs on the CI machines.  We 
expect the upgrade process to take an hour or two.  We’ll send out a message 
when the upgrade is complete.

Thanks!
nicole

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

Re: [swift-dev] libdispatch switched to CMake

[Michael Gottesman via swift-dev]

> On Sep 18, 2017, at 3:28 PM, Saleem Abdulrasool  wrote:
> 
> Hello swift-dev,
> 
> This change should be transparent to everyone, but, it still is a pretty big 
> milestone.
> 
> As of this afternoon, the non-Darwin builds use CMake to build libdispatch.  
> This work has been underway for quite some time, and we have finally switched 
> to that as the default on most targets.  This should be more or less 
> transparent to everyone developing with build-script or even invoking CMake 
> for swift directly.
> 
> This simplifies some of the logic for integrating the projects and avoid 
> unnecessary commands from being run.
> 
> Thanks particularly to Michael Gottesman, Chris Bieneman, Daniel Steffen, 
> David Grove, and Pierre Habouzit.  Sorry if I accidentally left someone off 
> the list!

+1!

For anyone listening in, if you run into any issues, you may need a clean build 
or a reconfigure.

Also in case anyone is not familiar with the bigger picture here, this down the 
line will enable us to eliminate autoconf as a dependency for building swift 
since libdispatch is the only part of swift now that depends on autoconf.

Michael

> 
> Saleem
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org

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

Re: [swift-dev] Changing ELF layout

[Saleem Abdulrasool via swift-dev]

On Mon, Sep 18, 2017 at 9:36 AM John McCall  wrote:

> On Sep 17, 2017, at 10:15 AM, Saleem Abdulrasool 
> wrote:
>
> On Sat, Sep 16, 2017 at 6:19 PM, John McCall  wrote:
>
>> > On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev <
>> swift-dev@swift.org> wrote:
>> > Hello,
>> >
>> > I'd like to propose that we change the locations that we use to store
>> the type metadata, protocol conformances, type references, reflection
>> strings, field metadata, and associated types.
>> >
>> > I think that it is possible to simplify the design for the linker
>> tables by changing section names and relying on the linker to perform the
>> work necessary to generate the tables so that they can be walked later.
>> >
>> > Switching sections would mean that we would lose interoperability with
>> previously built libraries.  Given that there is ABI stability work going
>> on for at least the Darwin target, I figure that this would be the best
>> time to do this.
>> >
>> > Would this be acceptable?  Is compatibility something that we need to
>> worry about?
>>
>> Compatibility is not something that we're currently promising.  I think
>> this is a fine time to be working on this problem.
>>
>> It's not clear from your proposal whether you're just proposing changing
>> sections or whether you're interested in more invasive changes to metadata
>> emission.  Can you be more specific.
>
>
> Certainly.
>
> Right now, we have two special object files which must be included in a
> certain order to ensure that the sections that I mentioned earlier are
> bounded and grouped.  However, this is unneessary.  As long as the section
> name is a valid C identifier, the linker will group and bound the sections
> with special variables that it will synthesize
> (__{start,stop}_[SectionName]).  This will allow us to replace the two file
> approach with a single file approach.  Furthermore, it will allow the file
> to be injected anywhere (it drops the need for the files to appear in a
> specific order).  Finally, it simplifies the logic so that we can write the
> entire thing in C rather than having to roll the begin/end content in
> assembly.
>
>
> Yes, if that's the case, that would be massively useful.
>
> The runtime needs to be able to find these bounds in an arbitrary image,
> since there may be multiple images in the program containing Swift code.
> Are those symbols available dynamically even if it they aren't used
> statically?
>

It should be possible to preserve the symbols.  In general, it is possible
to dead strip symbols.  So having the object that needs to be injected
reference them is sufficient to ensure that they aren't dead stripped.
After that, they can be dynamically looked up even if they aren't
statically used.

I'll try to get to this change soon!


> John.
>
>
> I think that this would help reduce some of the complexity of the ELF
> emission.  In particular, it would mean that we would change the following:
>
> .swift3_typeref -> swift3_type_references
> .swift3_reflstr -> swift3_reflection_strings
> .swift3_fieldmd -> swift3_field_metadata
> .swift3_assocty -> swift3_associated_types
>
> .swift2_protocol_conformances -> swift2_protocol_conformances
> .swift2_type_metadata -> swift2_type_metadata
>
> AFAIK, ELF does not impose section name limits, so, Im not sure if there
> is anything to gain from the shortened names.
>
> While we are changing these things around, it seems that it may be a good
> idea to also change the PE/COFF emission to use section grouping (as
> specified within the specification) so that we can have similar handling on
> both the ELF and COFF sides.
>
> In the case of PE/COFF, the only change would be the augmentation of the
> grouping specifier ($B) on the existing names.  The names already are
> within the specification limits (COFF limits section names to 8
> characters).  This would allow begin/end markers to be constructed.
>
>
>> John.
>>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
>
> --
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] libdispatch switched to CMake

[Saleem Abdulrasool via swift-dev]

Hello swift-dev,

This change should be transparent to everyone, but, it still is a pretty
big milestone.

As of this afternoon, the non-Darwin builds use CMake to build
libdispatch.  This work has been underway for quite some time, and we have
finally switched to that as the default on most targets.  This should be
more or less transparent to everyone developing with build-script or even
invoking CMake for swift directly.

This simplifies some of the logic for integrating the projects and avoid
unnecessary commands from being run.

Thanks particularly to Michael Gottesman, Chris Bieneman, Daniel Steffen,
David Grove, and Pierre Habouzit.  Sorry if I accidentally left someone off
the list!

Saleem

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Value-type bound protocols?

[Ben Cohen via swift-dev]

> On Sep 13, 2017, at 1:06 PM, David Zarzycki via swift-dev 
>  wrote:
> 
> 
> 
>> On Sep 13, 2017, at 15:23, Matthew Johnson via swift-dev 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Sep 13, 2017, at 11:56 AM, David Zarzycki via swift-dev 
>>>  wrote:
>>> 
>>> 
>>> 
 On Sep 13, 2017, at 13:53, David Sweeris  wrote:
 
 
> On Sep 13, 2017, at 09:54, David Zarzycki via swift-dev 
>  wrote:
> 
> Hello,
> 
> As a part of a research project that I’m working on, I’ve started bumping 
> into the need for value-type bound protocols (as opposed to the existing 
> class bound protocols). Is this something that would be worth proposing 
> formally? Or should I just keep the patch I have on my research branch?
 
 I think it'd be worth a proposal, especially if can talk about why you 
 needed it.
>>> 
>>> While I look forward to talking about my research, I’m not ready to do in 
>>> the near future.
>>> 
>>> That being said, value-type bound protocols seem independently useful and 
>>> that is why I emailed the list.
>>> 
>>> I think the use case for this is generic algorithms. Why? Because it can be 
>>> hard to impossible to write *robust* generic code when you don’t know 
>>> whether an abstract type copies by value or by reference during 
>>> assignment/initialization. With class-bound protocols, you can guarantee 
>>> reference semantics, but there is no analogous feature for ensuring value 
>>> semantics. I have a small (~150 line) patch that fixes this.
>> 
>> Value types and value semantics are not the same.  Most people who have 
>> asked for this capability actually want a constraint for value semantics, 
>> not value types.  Is that what you're asking for as well?
> 
> The patch that I’m ready to put forth is only a value-type bound. In other 
> words only structs and enums would be able to conform to a value-type bound 
> protocol. Enforcing value semantics is arguably a separable language goal.
> 

But knowing something is a value type isn’t particularly useful, given it 
doesn’t guarantee value semantics. It could even do more harm than good, by 
being confusable with enforcing value semantics. 

Can you go into the use cases you have where you would use the knowledge that a 
type is a value type?


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

Re: [swift-dev] New to building Swift toolchain

[Michael Gottesman via swift-dev]

> On Sep 18, 2017, at 8:54 AM, Maksym Grebenets via swift-dev 
>  wrote:
> 
> Hi all
> 
> I guess like many other iOS devs with c/c++ background I really wanted to get 
> into Swift development one day, at least a tiny bit, at least to understand 
> how things work.
> 
> So new refactoring tools and starter tasks finally pulled me in.
> 
> With a lot of struggle and a lot of help from community I was able to 
> understand how lit works, how to walk the AST and write changes back to the 
> editor. I've got code and tests for new refactoring kind and new refactoring 
> action, so I was like "yay, time to build the keychain and just try it in 
> Xcode!!!".
> 
> That's where I was thrown back to the "what do I do?" state again...
> 
> I pulled latest master branch and ran build-toolchain and all of that just to 
> be told after almost an hour or so that there are 3 failing tests...

What were the failing tests?

> 
> So I thought:
> 
> cd swift
> git checkout swift-DEVELOPMENT-SNAPSHOT-2017-09-15-a
> cd ..
> ./swift/utils/update-checkout --tag swift-DEVELOPMENT-SNAPSHOT-2017-09-15-a
> 
> then build and fail again :(...

So you are saying that you took the last "known good snapshot" and that also 
failed. How did it fail? On the same 3 tests?

> 
> OK then, so I just disable the tests and give it another go:
> 
> # build-presets.ini
> #test
> #validation-test
> #long-test
> 
> Yay! I got a toolchain!
> I copy it over to /Library/Developer/Toolchains/ 
> Select it in Xcode (latest Xcode 9 GM) and... no luck
> The source code highlighting disappears, 
> I get "An internal error occurred. Source editor functionality is limited..." 
> error.
> All of the refactoring actions are disabled.
> 
> I guess those 3 failing tests did matter in the end...
> 
> 
> I may be frustrated, because I don't understand what's going on, but I don't 
> feel like giving up.
> 
> I'd appreciate any help or advice I can get!
> 
> Should I choose an older tag from before to get all tests passing?

Do you mean before the last known good snapshot? If a snapshot was published on 
swift.org , it /should/ pass all of the tests.

> Should I build using Xcode beta rather then GM?

You should be using the Xcode beta. This can be seen either via the README.md 
under System Requirements for macOS [and don't worry I run into this issue 
sometimes as well = )]. It is also documented on the CI: https://ci.swift.org 
 with a nice link.

> Is there any way to build/re-build the OS X toolchain any faster? 
> Why does it take so long even if I just re-run same command again?

When you rerun is it not incremental? (I forgot TBH). In terms of the amount of 
work performed, build-toolchain command is intended to be used for producing 
snapshots and thus it has to be complete and include code for all 
platforms/etc. We could potentially have a preset that builds a toolchain only 
for 1 platform. I am not 100% sure if such a toolchain would work, but it 
should take significantly less time to build. Would that help?

> Where did I get it wrong so the toolchain doesn't really work with Xcode?
> Can I connect lldb to process that runs my lit tests?
> 
> I'm sorry for having so many questions, but you can imagine there isn't a lot 
> of information for newbies like me trying to get into Swift compiler 
> development. Well, let's just say I couldn't find much :) I've just realized 
> that this mail list is better option that StackOverflow about an hour ago :) 
> Though, of course, I have read Brian Gesiak's posts and the swift.org 
>  blog post on refactoring.

There are no bad questions or too many questions. Welcome to the dev-list = ).

> 
> Just to sum up all of the above, how to I get to build local Xcode toolchain 
> which I can plug in to Xcode and test?

Answer my questions above... I'll help you get across the finish line.

On another note, I noticed you mention starter tasks: keep in mind there are 
more starter tasks than have been documented. If you are interested in a 
specific area of the compiler and can not find starter tasks in this area, 
please feel free to send a nice email to this list. I am sure we can find 
/something/ ; ).

Michael

> 
> Thank you!
> ___
> 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] Changing ELF layout

[John McCall via swift-dev]

> On Sep 17, 2017, at 10:15 AM, Saleem Abdulrasool  
> wrote:
> 
> On Sat, Sep 16, 2017 at 6:19 PM, John McCall  > wrote:
> > On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev 
> > > wrote:
> > Hello,
> >
> > I'd like to propose that we change the locations that we use to store the 
> > type metadata, protocol conformances, type references, reflection strings, 
> > field metadata, and associated types.
> >
> > I think that it is possible to simplify the design for the linker tables by 
> > changing section names and relying on the linker to perform the work 
> > necessary to generate the tables so that they can be walked later.
> >
> > Switching sections would mean that we would lose interoperability with 
> > previously built libraries.  Given that there is ABI stability work going 
> > on for at least the Darwin target, I figure that this would be the best 
> > time to do this.
> >
> > Would this be acceptable?  Is compatibility something that we need to worry 
> > about?
> 
> Compatibility is not something that we're currently promising.  I think this 
> is a fine time to be working on this problem.
> 
> It's not clear from your proposal whether you're just proposing changing 
> sections or whether you're interested in more invasive changes to metadata 
> emission.  Can you be more specific.
> 
> Certainly.
> 
> Right now, we have two special object files which must be included in a 
> certain order to ensure that the sections that I mentioned earlier are 
> bounded and grouped.  However, this is unneessary.  As long as the section 
> name is a valid C identifier, the linker will group and bound the sections 
> with special variables that it will synthesize 
> (__{start,stop}_[SectionName]).  This will allow us to replace the two file 
> approach with a single file approach.  Furthermore, it will allow the file to 
> be injected anywhere (it drops the need for the files to appear in a specific 
> order).  Finally, it simplifies the logic so that we can write the entire 
> thing in C rather than having to roll the begin/end content in assembly.

Yes, if that's the case, that would be massively useful.

The runtime needs to be able to find these bounds in an arbitrary image, since 
there may be multiple images in the program containing Swift code.  Are those 
symbols available dynamically even if it they aren't used statically?

John.

> 
> I think that this would help reduce some of the complexity of the ELF 
> emission.  In particular, it would mean that we would change the following:
> 
> .swift3_typeref -> swift3_type_references
> .swift3_reflstr -> swift3_reflection_strings
> .swift3_fieldmd -> swift3_field_metadata
> .swift3_assocty -> swift3_associated_types
> 
> .swift2_protocol_conformances -> swift2_protocol_conformances
> .swift2_type_metadata -> swift2_type_metadata
> 
> AFAIK, ELF does not impose section name limits, so, Im not sure if there is 
> anything to gain from the shortened names.
> 
> While we are changing these things around, it seems that it may be a good 
> idea to also change the PE/COFF emission to use section grouping (as 
> specified within the specification) so that we can have similar handling on 
> both the ELF and COFF sides.
> 
> In the case of PE/COFF, the only change would be the augmentation of the 
> grouping specifier ($B) on the existing names.  The names already are within 
> the specification limits (COFF limits section names to 8 characters).  This 
> would allow begin/end markers to be constructed.
> 
> 
> John.
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org

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

[swift-dev] New to building Swift toolchain

[Maksym Grebenets via swift-dev]

Hi all

I guess like many other iOS devs with c/c++ background I really wanted to
get into Swift development one day, at least a tiny bit, at least to
understand how things work.

So new refactoring tools and starter tasks finally pulled me in.

With a lot of struggle and a lot of help from community I was able to
understand how lit works, how to walk the AST and write changes back to the
editor. I've got code and tests for new refactoring kind and new
refactoring action, so I was like "yay, time to build the keychain and just
try it in Xcode!!!".

That's where I was thrown back to the "what do I do?" state again...

I pulled latest *master* branch and ran *build-toolchain *and all of that
just to be told after almost an hour or so that there are 3 failing tests...

So I thought:

cd swift
git checkout swift-DEVELOPMENT-SNAPSHOT-2017-09-15-a
cd ..
./swift/utils/update-checkout --tag swift-DEVELOPMENT-SNAPSHOT-2017-09-15-a

then build and fail again :(...

OK then, so I just disable the tests and give it another go:

# build-presets.ini
#test
#validation-test
#long-test

Yay! I got a toolchain!
I copy it over to /Library/Developer/Toolchains/
Select it in Xcode (latest Xcode 9 GM) and... no luck
The source code highlighting disappears,
I get "An internal error occurred. Source editor functionality is
limited..." error.
All of the refactoring actions are disabled.

I guess those 3 failing tests did matter in the end...


I may be frustrated, because I don't understand what's going on, but I
don't feel like giving up.

I'd appreciate any help or advice I can get!

Should I choose an older tag from before to get all tests passing?
Should I build using Xcode beta rather then GM?
Is there any way to build/re-build the OS X toolchain any faster?
Why does it take so long even if I just re-run same command again?
Where did I get it wrong so the toolchain doesn't really work with Xcode?
Can I connect lldb to process that runs my lit tests?

I'm sorry for having so many questions, but you can imagine there isn't a
lot of information for newbies like me trying to get into Swift compiler
development. Well, let's just say I couldn't find much :) I've just
realized that this mail list is better option that StackOverflow about an
hour ago :) Though, of course, I have read Brian Gesiak's posts and the
swift.org blog post on refactoring.

Just to sum up all of the above, how to I get to build local Xcode
toolchain which I can plug in to Xcode and test?

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.04 (master) #581

[Ian Partridge via swift-dev]

There's a PR open to fix this intermittent failure:
https://github.com/apple/swift-corelibs-foundation/pull/1218

On 18 September 2017 at 11:07, Ankit Aggarwal via swift-dev <
swift-dev@swift.org> wrote:

> Looks like a failure in corelibs-foundation:
>
> Test Case 'TestThread.test_threadStart' started at 2017-09-18 
> 10:05:03.040TestFoundation/TestThread.swift:54: error: 
> TestThread.test_threadStart : XCTAssertTrue failed - NSCondition wait timed 
> outTest Case 'TestThread.test_threadStart' failed (10.014 seconds)
>
>
>
> On 18-Sep-2017, at 3:35 PM, no-re...@swift.org wrote:
>
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#581]
> Build URL: https://ci.swift.org/job/oss-swift-incremental-RA-linux-
> ubuntu-16_04/581/
> Project: oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build: Mon, 18 Sep 2017 04:31:16 -0500
> Build duration: 35 minIdentified 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: 9895 test(s), Total: 9895 test(s)
> Name: *Swift-Unit*
> Failed: 0 test(s), Passed: 461 test(s), Total: 461 test(s)
>
> Changes
>
>- Commit *10812ba83a1c881fd962ad7355bb9e93d6ec7f89* by
>*ankit_aggarwal:*
>
>[WorkspaceTests] Migrate testCanResolveWithIncompatiblePins
>- *edit*: Tests/WorkspaceTests/WorkspaceTests2.swift
>   - *edit*: Tests/WorkspaceTests/WorkspaceTests.swift
>
>
>
> --
> Ankit
>
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>


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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.04 (master) #581

[Ankit Aggarwal via swift-dev]

Looks like a failure in corelibs-foundation:

Test Case 'TestThread.test_threadStart' started at 2017-09-18 10:05:03.040
 <>TestFoundation/TestThread.swift:54: error: TestThread.test_threadStart : 
XCTAssertTrue failed - NSCondition wait timed out
Test Case 'TestThread.test_threadStart' failed (10.014 seconds)


> On 18-Sep-2017, at 3:35 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#581]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/581/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Mon, 18 Sep 2017 04:31:16 -0500
> Build duration:   35 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: 9895 test(s), Total: 9895 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 461 test(s), Total: 461 test(s)
> 
> Changes
> 
> Commit 10812ba83a1c881fd962ad7355bb9e93d6ec7f89 by ankit_aggarwal:
> [WorkspaceTests] Migrate testCanResolveWithIncompatiblePins
> 
> edit: Tests/WorkspaceTests/WorkspaceTests2.swift
> edit: Tests/WorkspaceTests/WorkspaceTests.swift


--
Ankit

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