Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

2016-05-29 Thread Brian Croom via swift-corelibs-dev 
That's right, breaking changes have been made to Swift since the latest
toolchain snapshot was released, and Corelibs Foundation has been updated
accordingly.

Until the next snapshot, an alternative to building your own toolchain
would be to check out an older commit of Foundation which still builds with
the compiler in the snapshot toolchain, since XCTest doesn't depend on any
of the more recent Foundation changes. I've had success using this commit:
https://github.com/apple/swift-corelibs-foundation/commit/04d4f92870652160388f1c69de3fd7bb0656860c


--Brian

söndag 29 maj 2016 skrev Brian Gesiak via swift-corelibs-dev <
[email protected]>:

> Madhu,
>
> Oy, my bad -- I only just noticed you put the toolchain version at the
> bottom of your original email.
>
> It's possible the May 9th toolchain is already too old to build XCTest.
> I'll double-check myself. In the meantime, you may want to try building
> your own toolchain and using that.
>
> - Brian Gesiak
>
>
>
>
>
> On Sun, May 29, 2016 at 7:23 AM -0700, "Brian Gesiak"  > wrote:
>
> Madhu,
>>
>> Thanks for the report!
>>
>> The main difference between the build scripts (which use xcodebuild) and
>> using Xcode itself is the version of Swift that is used. The build scripts
>> build a Swift 3.0 compiler, then use that to build XCTest. When using Xcode
>> directly, you need to select a recent Swift toolchain yourself.
>>
>> Which Swift toolchain are you using to compile XCTest in Xcode?
>>
>> Our tests only make sure apple/swift master works. If the latest Swift
>> toolchain from http://swift.org doesn't work, you may have to built your
>> own toolchain. You can do so using the `utils/build-toolchain` script in
>> the Swift repository.
>>
>> Once you figure out your Swift toolchain version, let us know! You should
>> be able to find out in the preferences pane in Xcode.
>>
>> - Brian Gesiak
>>
>>
>>
>>
>>
>> On Sun, May 29, 2016 at 1:24 AM -0700, "Madhu Samuel via
>> swift-corelibs-dev" > > wrote:
>>
>> Hi All,
>>>
>>> I am new to this forum.
>>>
>>> I am trying to build the xctest project. I followed the instructions at
>>> https://github.com/apple/swift-corelibs-xctest
>>>
>>> I am able to successfully build via the build scripts. But, if I build
>>> XCTest using xcode using the SwiftXCTest scheme I am getting a few errors.
>>>
>>> 1. swift-corelibs-foundation/Foundation/NSXMLDTDNode.swift:242:64:
>>> error: cannot convert value of type 'UnsafeMutablePointer' (aka
>>> 'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'
>>> let unmanaged =
>>> Unmanaged.fromOpaque(privateData)
>>>
>>> 2. swift-corelibs-foundation/Foundation/NSTimer.swift:14:47: error:
>>> cannot convert value of type 'UnsafeMutablePointer' (aka
>>> 'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'
>>> let t = Unmanaged.fromOpaque(info!).takeUnretainedValue()
>>>
>>> etc.
>>>
>>> My dev environment,
>>> OS: Mac OSX El Capitan 10.11.4 (15E65).
>>> Xcode Version: Version 7.3.1 (7D1014)
>>> XCode Toolchain: Swift Development Snapshot 2016-05-09 (a)
>>>
>>> Any help is appreciated.
>>>
>>> Regards,
>>> Madhu
>>>
>>>
>>>
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] libdispatch on Linux, or C++ std::async?

2016-05-30 Thread Brian Croom via swift-corelibs-dev 
I've noticed that there is a submodule reference to libpwq (see
https://github.com/apple/swift-corelibs-libdispatch/blob/master/.gitmodules).
Is it possible that the submodule hasn't been initialized in your clone?

måndag 30 maj 2016 skrev Brian Gesiak via swift-corelibs-dev <
[email protected]>:

> Thanks for the quick responses!
>
> I had tried the experimental/foundation branch as well, with no luck.
> Here's the full output from a clean build I just attempted:
> https://gist.github.com/modocache/fcf0c78908b39834448c73ac3f50c110
>
> Prior to the build I removed my entire build directory (which included
> both libdispatch-linux-x86_64 and swift-linux-x86_64) and removed all build
> artifacts from my libdispatch directory (I used `git clean -fxd` -- Make
> tells me there's no target `distclean`).
>
> Looking at the build failure, it appears to be the same one that was
> reported in https://bugs.swift.org/browse/SR-1242. The author of that
> report indicates that
> https://github.com/apple/swift-corelibs-libdispatch/pull/64 fixes the
> problem. My checkout includes the commits from that pull request, but the
> problem remains.
>
> In any case, thanks for all your help! I'll keep trying. Any and all
> advice would be much appreciated!
>
> - Brian Gesiak
>
>
> On Mon, May 30, 2016 at 10:22 AM, Chris Bailey  > wrote:
>
>> I'd certainly recommend picking up the experimental/foundation branch as
>> Rob recommends. Its where we've been doing some additional work to get
>> properly built into the Swift toolchain and to open up some internal APIs
>> needed by Foundation.
>>
>> Whilst I've been building Dispatch either independently or as part of a
>> full toolchain using the buildbot_linux preset (with dispatch and
>> install-dispatch added), I've just checked your build line and its working
>> fine for me. It might be worth cleaning out any partial build you might
>> have of libdispatch in your build directory, and running 'make distclean'
>> from your libdispatch source directory.
>>
>> FYI, we've got some further changes to the experimental/foundation branch
>> of libdispatch with should land in the next couple of days. This fixes some
>> issues with the Swift overlay, and resolves a crash that we've found in the
>> underlying libkqueue implementation.
>>
>> Chris
>>
>>
>>
>>
>> From:Rob Allen via swift-corelibs-dev <
>> [email protected]
>> >
>> To:Brian Gesiak > >
>> Cc:Swift Core Libs > >
>> Date:30/05/2016 08:08
>> Subject:Re: [swift-corelibs-dev] libdispatch on Linux, or C++
>> std::async?
>> Sent by:[email protected]
>> 
>> --
>>
>>
>>
>> Hi,
>>
>> For what it's worth, I can't get the master branch to build either, but I
>> can get the experimental/foundation branch to build.
>>
>> Regards,
>>
>> Rob
>>
>>
>> On 30 May 2016, at 05:28, Brian Gesiak via swift-corelibs-dev <
>> *[email protected]*
>> > wrote:
>>
>> Hello all!
>>
>> I'm working on *https://bugs.swift.org/browse/SR-710*
>> , which involves porting SourceKit
>> to Linux. SourceKit contains a handful of references to libdispatch symbols.
>>
>> I have two questions:
>>
>> 1. Could someone share a set of instructions to build
>> swift-corelibs-libdispatch on Linux? I'm using Ubuntu 15.10 and have
>> installed [the dependencies listed here](
>> *https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20151207/000122.html*
>> ).
>> I have tried using both `swift/utils/build-script --libdispatch` as well as
>> the instructions in the swift-corelibs-libdispatch `INSTALL` file. Both
>> fail with the [same errors](
>> *https://gist.github.com/modocache/8389d5d64e39ca5a4281500f84e9ce11*
>> ).
>> Any tips?
>>
>> 2. I don't know much about C++, but from what I understand the C++ stdlib
>> provides tools for asynchronous programming. I list SourceKit's uses of
>> libdispatch in a comment on *https://bugs.swift.org/browse/SR-1639*
>> . For those familiar with both
>> C++ and libdispatch: do you think it's a good idea to migrate to C++, at
>> least for now?
>>
>> Any advice would be appreciated. Thanks!!
>>
>> - Brian Gesiak
>>
>>
>> --
>> Development thoughts at *http://akrabat.com* 
>> Daily Jotter for Mac OS X at *http://dailyjotter.com*
>> 
>> ___
>> swift-corelibs-dev mailing list
>> [email protected]
>> 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>
>>
>>
>
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] libdispatch on Linux, or C++ std::async?

2016-05-30 Thread Brian Croom via swift-corelibs-dev 
I have no hands-on experience with it itself, but my understanding is that
the std::async API in the current standards is pretty severely flawed and
makes it awfully easy to shoot yourself in the foot. On the other hand, the
libdispatch usage here does appear to be pretty basic.

Hopefully someone with more expertise can weigh in still!

måndag 30 maj 2016 skrev Brian Gesiak via swift-corelibs-dev <
[email protected]>:

> Gah, thanks Brian and Chris -- yes, I had forgotten. I initialized it once
> on a separate development environment and forgot to do so again.
>
> Thanks everyone! I managed to build the project. :)
>
> I'll try getting SourceKit to link against my built libdispatch. Does
> anyone have any thoughts on my second question? Would it make sense to move
> SourceKit over to C++ async features? SourceKit only uses the following
> libdispatch symbols:
>
> - dispatch_after
> - dispatch_release
> - dispatch_semaphore_create
> - dispatch_semaphore_signal
> - dispatch_semaphore_wait
> - dispatch_time
>
> As far as I understand, having SourceKit use libdispatch means:
>
> 1. Having libdispatch built as part of all Swift builds that build
> SourceKit. On OS X, most buildbot presets build SourceKit. I'd like to do
> the same for Linux.
> 2. Building libdispatch prior to building Swift, or at least prior to
> building Swift tools like SourceKit.
>
> Moving these build dependencies around seems like more work than using C++
> async, but I barely know C++, so I'm not sure. Thoughts?
>
> - Brian Gesiak
>
>
> On Mon, May 30, 2016 at 12:19 PM, Chris Bailey  > wrote:
>
>> The missing reference is to 'pthread_workqueue_signal_np()' which was
>> added to libpwq via PR #10:
>> https://github.com/mheily/libpwq/pull/10
>>
>> I suspect that you don't have the libpwq submodule checked out in
>> swift-corelibs-libdispatch. Is there any contents in
>> swift-corelibs-libdispatch/libpwq?
>>
>> If not, running:
>> git submodule init
>> git submodule update
>> from the swift-corelibs-libdispatch directory should fix it.
>>
>> Chris
>>
>>
>>
>>
>> From:Brian Gesiak > >
>> To:Chris Bailey/UK/IBM@IBMGB
>> Cc:Rob Allen > >, Swift Core Libs <
>> [email protected]
>> >
>> Date:30/05/2016 16:51
>> Subject:Re: [swift-corelibs-dev] libdispatch on Linux, or C++
>> std::async?
>> --
>>
>>
>>
>> Thanks for the quick responses!
>>
>> I had tried the experimental/foundation branch as well, with no luck.
>> Here's the full output from a clean build I just attempted:
>> *https://gist.github.com/modocache/fcf0c78908b39834448c73ac3f50c110*
>> 
>>
>> Prior to the build I removed my entire build directory (which included
>> both libdispatch-linux-x86_64 and swift-linux-x86_64) and removed all build
>> artifacts from my libdispatch directory (I used `git clean -fxd` -- Make
>> tells me there's no target `distclean`).
>>
>> Looking at the build failure, it appears to be the same one that was
>> reported in *https://bugs.swift.org/browse/SR-1242*
>> . The author of that report
>> indicates that
>> *https://github.com/apple/swift-corelibs-libdispatch/pull/64*
>>  fixes the
>> problem. My checkout includes the commits from that pull request, but the
>> problem remains.
>>
>> In any case, thanks for all your help! I'll keep trying. Any and all
>> advice would be much appreciated!
>>
>> - Brian Gesiak
>>
>>
>> On Mon, May 30, 2016 at 10:22 AM, Chris Bailey <*[email protected]*
>> > wrote:
>> I'd certainly recommend picking up the experimental/foundation branch as
>> Rob recommends. Its where we've been doing some additional work to get
>> properly built into the Swift toolchain and to open up some internal APIs
>> needed by Foundation.
>>
>> Whilst I've been building Dispatch either independently or as part of a
>> full toolchain using the buildbot_linux preset (with dispatch and
>> install-dispatch added), I've just checked your build line and its working
>> fine for me. It might be worth cleaning out any partial build you might
>> have of libdispatch in your build directory, and running 'make distclean'
>> from your libdispatch source directory.
>>
>> FYI, we've got some further changes to the experimental/foundation branch
>> of libdispatch with should land in the next couple of days. This fixes some
>> issues with the Swift overlay, and resolves a crash that we've found in the
>> underlying libkqueue implementation.
>>
>> Chris
>>
>>
>>
>>
>> From:Rob Allen via swift-corelibs-dev <
>> *[email protected]*
>> >
>> To:Brian Gesiak <*[email protected]*
>> >
>> Cc:Swift Core Libs <*[email protected]*
>> >
>> Date:30/05/2016 08:08
>> Subject:Re: [swift-corelibs-dev] libdispatch on Linux, or C++
>> std::async?
>>

Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

2016-06-20 Thread Brian Croom via swift-corelibs-dev 
Hmm, have you tried deleting your `build/swift-macosx-x86_64/` directory? I
wonder if cached CMake values could cause that issue.

(By the way, I can confirm that getting the build going for the first time
is the most challenging! I hope we can get things going for you soon.)

2016-06-20 22:22 GMT-04:00 Madhu Samuel :

> So after spending almost a week trying to build swift and core libraries
> (mainly xctest) during the end of May un-successfully, I made up my mind to
> give another attempt today.
>
> I checkout the latest code from swift repo. Since the xctest documentation
> says, "Confirm you're able to build the Swift project using
> utils/build-script -R", that's where I started.
>
> Unfortunately, build-script -R gives the below error.
>
> :0: error: Swift does not support the SDK 'MacOSX10.11.sdk'
>
>
> My active developer directory is
> '/Applications/Xcode-beta.app/Contents/Developer'.
> The toolchain is 'Xode 8.0'
>
> The build is taken in Mac OSX El Capitan 10.11.4
>
> Let me know whether I miss anything? I assume getting the build working
> for the first time is the hardest, but there I am!
>
> Any help is appreciated!
>
> Regards,
> Madhu
>
> On Mon, May 30, 2016 at 8:32 AM, Madhu Samuel 
> wrote:
>
>> Wow, that was a quick response. Thanks Brian Gesiak and Brian Croom.
>>
>> My first quick attempt using build-toolchain script to build my own tool
>> chain failed. Anyway I will give it another try and let you know the status.
>>
>> On Mon, May 30, 2016 at 1:52 AM, Brian Croom 
>> wrote:
>>
>>> That's right, breaking changes have been made to Swift since the latest
>>> toolchain snapshot was released, and Corelibs Foundation has been updated
>>> accordingly.
>>>
>>> Until the next snapshot, an alternative to building your own toolchain
>>> would be to check out an older commit of Foundation which still builds with
>>> the compiler in the snapshot toolchain, since XCTest doesn't depend on
>>> any of the more recent Foundation changes. I've had success using this
>>> commit:
>>> https://github.com/apple/swift-corelibs-foundation/commit/04d4f92870652160388f1c69de3fd7bb0656860c
>>>
>>>
>>> --Brian
>>>
>>>
>>> söndag 29 maj 2016 skrev Brian Gesiak via swift-corelibs-dev <
>>> [email protected]>:
>>>
 Madhu,

 Oy, my bad -- I only just noticed you put the toolchain version at the
 bottom of your original email.

 It's possible the May 9th toolchain is already too old to build XCTest.
 I'll double-check myself. In the meantime, you may want to try building
 your own toolchain and using that.

 - Brian Gesiak





 On Sun, May 29, 2016 at 7:23 AM -0700, "Brian Gesiak" <
 [email protected]> wrote:

 Madhu,
>
> Thanks for the report!
>
> The main difference between the build scripts (which use xcodebuild)
> and using Xcode itself is the version of Swift that is used. The build
> scripts build a Swift 3.0 compiler, then use that to build XCTest. When
> using Xcode directly, you need to select a recent Swift toolchain 
> yourself.
>
> Which Swift toolchain are you using to compile XCTest in Xcode?
>
> Our tests only make sure apple/swift master works. If the latest Swift
> toolchain from http://swift.org doesn't work, you may have to built
> your own toolchain. You can do so using the `utils/build-toolchain` script
> in the Swift repository.
>
> Once you figure out your Swift toolchain version, let us know! You
> should be able to find out in the preferences pane in Xcode.
>
> - Brian Gesiak
>
>
>
>
>
> On Sun, May 29, 2016 at 1:24 AM -0700, "Madhu Samuel via
> swift-corelibs-dev"  wrote:
>
> Hi All,
>>
>> I am new to this forum.
>>
>> I am trying to build the xctest project. I followed the instructions
>> at https://github.com/apple/swift-corelibs-xctest
>>
>> I am able to successfully build via the build scripts. But, if I
>> build XCTest using xcode using the SwiftXCTest scheme I am getting a few
>> errors.
>>
>> 1. swift-corelibs-foundation/Foundation/NSXMLDTDNode.swift:242:64:
>> error: cannot convert value of type 'UnsafeMutablePointer' (aka
>> 'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'
>> let unmanaged =
>> Unmanaged.fromOpaque(privateData)
>>
>> 2. swift-corelibs-foundation/Foundation/NSTimer.swift:14:47: error:
>> cannot convert value of type 'UnsafeMutablePointer' (aka
>> 'UnsafeMutablePointer<()>') to expected argument type 'OpaquePointer'
>> let t = Unmanaged.fromOpaque(info!).takeUnretainedValue()
>>
>> etc.
>>
>> My dev environment,
>> OS: Mac OSX El Capitan 10.11.4 (15E65).
>> Xcode Version: Version 7.3.1 (7D1014)
>> XCode Toolchain: Swift Development Snapshot 2016-05-09 (a)
>>
>> Any help is appreciated.
>>
>> Regards,
>

Re: [swift-corelibs-dev] [XCTest] Cannot build using XCode

2016-07-05 Thread Brian Croom via swift-corelibs-dev 
Hmm, it does look like XCTest needs some work done to get things working
with the latest Swift 3 changes made in the stdlib and corelibs-foundation.
I don't have access to a development environment to investigate further,
but as far as I can tell, this wouldn't build on Linux either. Has there
been any indication of these issues from CI, I wonder?

On Friday, 1 July 2016, Madhu Samuel  wrote:

> I just found more error details in the log. You can find it below. Hope
> this helps.
>
> Error 1
> --
>
> CompileSwift normal x86_64
> /Users/madhusamuel/dev/swift/swift-corelibs-xctest/Sources/XCTest/Public/XCTestMain.swift
> cd /Users/madhusamuel/dev/swift/swift-corelibs-xctest
> ...
> ...
> /Users/madhusamuel/dev/swift/swift-corelibs-xctest/Sources/XCTest/Public/XCTestMain.swift:65:71:
> error: 'lastPathComponent' is unavailable: Use lastPathComponent on URL
> instead.
> currentTestSuite = XCTestSuite(name:
> "\(testBundle.bundlePath.lastPathComponent).xctest")
>
> ^
> SwiftFoundation.String:173:16: note: 'lastPathComponent' has been
> explicitly marked unavailable here
> public var lastPathComponent: String { get }
>^
>
>
> Error 2
> --
> CompileSwift normal x86_64
> /Users/madhusamuel/dev/swift/swift-corelibs-xctest/Sources/XCTest/Private/TestListing.swift
> cd /Users/madhusamuel/dev/swift/swift-corelibs-xctest
> ...
> ...
> /Objects-normal/x86_64/TestListing.swiftdeps -o
> /Users/madhusamuel/dev/swift/build/Ninja-ReleaseAssert/xctest-macosx-x86_64/XCTest.build/Debug/SwiftXCTest.build/Objects-normal/x86_64/TestListing.o
> /Users/madhusamuel/dev/swift/swift-corelibs-xctest/Sources/XCTest/Private/TestListing.swift:45:46:
> error: cannot convert value of type 'String.Encoding' to expected argument
> type 'UInt'
> print(NSString(data: json, encoding: NSUTF8StringEncoding)!)
>  ^~~~
>  .rawValue
> Assertion failed: (!failed && "Call arguments did not match up?"),
> function coerceCallArguments, file
> /Users/madhusamuel/dev/swift/swift/lib/Sema/CSApply.cpp, line 4655.
> 0  swift0x00010b6a6d5b
> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 43
> 1  swift0x00010b6a5f86
> llvm::sys::RunSignalHandlers() + 70
> 2  swift0x00010b6a7631 SignalHandler(int) + 641
> 3  libsystem_platform.dylib 0x7fff8ecf552a _sigtramp + 26
> 4  swift0x00010c290579 cmark_strbuf__initbuf +
> 73960
> 5  swift0x00010b6a727e abort + 14
> 6  swift0x00010b6a7261 __assert_rtn + 81
> 7  swift0x000108ff5bae (anonymous
> namespace)::ExprRewriter::coerceCallArguments(swift::Expr*, swift::Type,
> llvm::PointerUnion int, 2> >, swift::constraints::ConstraintLocatorBuilder) + 6190
> 8  swift0x000108fe4b0d (anonymous
> namespace)::ExprRewriter::finishApply(swift::ApplyExpr*, swift::Type,
> swift::constraints::ConstraintLocatorBuilder) + 541
> 9  swift0x000108ff638e (anonymous
> namespace)::ExprRewriter::visitApplyExpr(swift::ApplyExpr*) + 78
> 10 swift0x000108fe2325 (anonymous
> namespace)::ExprRewriter::walkToExprPost(swift::Expr*) + 21
> 11 swift0x000109180db0 (anonymous
> namespace)::Traversal::visit(swift::Expr*) + 160
> 12 swift0x000109182969 (anonymous
> namespace)::Traversal::visit(swift::Expr*) + 7257
> 13 swift0x000109180145
> swift::Expr::walk(swift::ASTWalker&) + 53
> 14 swift0x000108fdedcb
> swift::constraints::ConstraintSystem::applySolution(swift::constraints::Solution&,
> swift::Expr*, swift::Type, bool, bool, bool) + 475
> 15 swift0x000109081e53
> swift::TypeChecker::typeCheckExpression(swift::Expr*&, swift::DeclContext*,
> swift::TypeLoc, swift::ContextualTypePurpose,
> swift::OptionSet,
> swift::ExprTypeCheckListener*) + 739
> 16 swift0x0001090f9fc4
> swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*,
> void, void, void, void>::visit(swift::Stmt*) + 4820
> 17 swift0x0001090f8e3e
> swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*,
> void, void, void, void>::visit(swift::Stmt*) + 334
> 18 swift0x0001090f93d3
> swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*,
> void, void, void, void>::visit(swift::Stmt*) + 1763
> 19 swift0x0001090f8e3e
> swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*,
> void, void, void, void>::visit(swift::Stmt*) + 334
> 20 swift0x0001090f81f9 (anonymous
> namespace)::StmtChecker:

Re: [swift-corelibs-dev] [swift-dev] Swift CI PR builder dispatch linux failure

2016-09-26 Thread Brian Croom via swift-corelibs-dev 
When I was working this summer on getting SourceKit to build on Linux, one
challenge I encountered with getting the build to work cleanly was that
SourceKit is in the Swift repo, but it has a dependency on libdispatch.
Moving the dispatch overlay code such that libdispatch could always be
built before Swift would solve that problem nicely as well.

2016-09-25 12:26 GMT-07:00 Michael Gottesman via swift-dev <
[email protected]>:

>
> On Sep 25, 2016, at 11:38 AM, David P Grove via swift-dev <
> [email protected]> wrote:
>
> The order may need to vary by platform. On Linux, the DIspatch Swift
> overlay code lives in swift-corelibs-libdispatch/src/swift. So it works
> to build (1) Swift (2) libdispatch (both C and Swift) (3) Foundation.
>
> Question. Maybe the right thing to do is move the overlay even on OS X
> into swift. (Just trying to ask obvious questions).
>
>
> --dave
>
> Jordan Rose ---09/23/2016 06:34:46 PM---I think the right
> order to build things is: 1. libdispatch (C)
>
>
> From: Jordan Rose 
> To: David P Grove/Watson/IBM@IBMUS
> Cc: "Daniel A. Steffen" , swift-dev <
> [email protected]>, swift-corelibs-dev 
> Date: 09/23/2016 06:34 PM
> Subject: Re: [swift-dev] Swift CI PR builder dispatch linux failure
> Sent by: [email protected]
>
> --
>
>
>
> I think the right order to build things is:
>
> 1. libdispatch (C)
> 2. Swift (compiler + stdlib + Dispatch overlay)
> 3. Foundation
>
> Otherwise we need to build Swift, then build libdispatch, then go back to
> "Swift" to build the overlay, and only finally get to Foundation.
>
> Jordan
>
>
>On Sep 23, 2016, at 14:32, David P Grove via swift-dev <
>   *[email protected]* > wrote:
>
>   I'm playing with something. Should have a PR ready shortly.
>
>   --dave
>
>
>   "Daniel A. Steffen via swift-dev" ---09/23/2016
>   04:45:06 PM---I don’t know how these dependencies are expressed in CMake
>   but it doesn’t seem very difficult to do
>
>   From: "Daniel A. Steffen via swift-dev" <*[email protected]*
>   >
>   To: Ted Kremenek <*[email protected]* >
>   Cc: swift-dev <*[email protected]* >
>   Date: 09/23/2016 04:45 PM
>   Subject: Re: [swift-dev] Swift CI PR builder dispatch linux failure
>   Sent by: *[email protected]* 
>
>   --
>
>
>
>   I don’t know how these dependencies are expressed in CMake but it
>   doesn’t seem very difficult to do so in the autotools buildsystem, we 
> have
>
>   AC_ARG_WITH([swift-toolchain],
>   [AS_HELP_STRING([--with-swift-toolchain], [Specify path to Swift
>   toolchain])],
>   [swift_toolchain_path=${withval}
>   AC_DEFINE(HAVE_SWIFT, 1, [Define if building for Swift])
>   SWIFTC="$swift_toolchain_path/bin/swiftc”
>
>   in configure.ac which ends up as a SWIFTC makefile variable, so as
>   long as that argument is passed as an absolute path, it should work as a
>   dependency in the build rules
>
>   $(abs_builddir)/swift/%.o: $(abs_srcdir)/swift/%.swift
>   $(SWIFTC) -frontend -c $(SWIFT_ABS_SRC_FILES) -primary-file $< \
>
>   Is there a JIRA ticket for this ? the IBM folks should probably be
>   the ones making these changes since we still don’t have the whitelist in
>   place for Apple contributors to do so…
>
>   Daniel
>   On Sep 23, 2016, at 13:00, Ted Kremenek <*[email protected]*
>   > wrote:
>
>   + Daniel
>
> * Daniel*: how hard would it be for the Dispatch project to be modified
>   to add the swiftc binary used to build the project as a 
> dependency?
>  On Sep 23, 2016, at 12:55 PM, Ted Kremenek via
>   swift-dev <*[email protected]*
>   > wrote:
>
>   Dispatch is a separate project. There isn’t
>   a dependency in the Dispatch project to tell it 
> is building with a new
>   compiler. The project would need to be modified 
> to add a dependency on the
>   swiftc binary being used to compile this 
> project.
>  On Sep 21, 2016, at 9:39 AM, Mishal Shah
>   via swift-dev <
>   *[email protected]*
>   > wrote:
>
>   We should look into why it's
>   not rebuilding dependencies. Do we 
> need to fix CMake logic? Can you please
>   file a bug?
>
>
>   Thanks,
>   Mishal Shah
>
>   On Sep 21, 2016, at 9:28 AM,
>   Michael Gottesman <
>

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

2017-01-27 Thread Brian Croom via swift-corelibs-dev 
This seems to be the same failure as here from yesterday:

https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/164/console

I'm pretty confident there haven't been any changes in XCTest in weeks that
would account for a memory error like this.

On Fri, Jan 27, 2017 at 1:33 PM Jordan Rose via swift-dev <
[email protected]> wrote:

> None of these changes would have affected the failing XCTest test. Adding
> swift-corelibs-dev.
> https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-14_04/775/consoleFull#-936285465fca400bf-2f4a-462e-b517-e058d770b2d7
>
> *** Error in
> `/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates':
> double free or corruption (fasttop): 0x7f7108000a70 ***
>
> error: command failed with exit status: -6
> $ "true"
> $
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker.py"
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/main.swift.tmp"
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift"
> # command stderr:
> Traceback (most recent call last):
>   File
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker.py",
> line 15, in 
> xctest_checker.main.main()
>   File
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker/main.py",
> line 61, in main
> compare.compare(args.actual, args.expected, args.check_prefix)
>   File
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker/compare.py",
> line 85, in compare
> repr(expected_line)))
> xctest_checker.error.XCTestCheckerError:
>
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:26:
> There were more lines expected to appear than there were lines in the
> actual input. Unmet expectation:
> '.*/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:32:
> error:
> PredicateExpectationsTestCase.test_immediatelyFalsePredicateAndObject_fails
> : Asynchronous wait failed - Exceeded timeout of 0.1 seconds, with
> unfulfilled expectations: Expect `` for
> object '
>
>
>
>
> On Jan 27, 2017, at 12:05, [email protected] wrote:
>
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#775]
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/775/
> Project: oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build: Fri, 27 Jan 2017 11:31:23 -0800
> Build duration: 33 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
>   
> 
>- Regression test failed: This build failed because a regression test
>in the test suite FAILed. Below is a list of all errors:
>   - Indication 1
>   
> 
>
>
> Changes
>
>- Commit *98ead6bf0471f4d7762aeb47b907b9897252a8d4* by *jordan_rose:*
>
>[Verifier] Always check function DeclName / ParamDecl matches.
>- *edit*: lib/AST/ASTVerifier.cpp
>
>- Commit *4020f49f8ee794b8383fff8d2e917311ef678055* by *jordan_rose:*
>
>[Verifier] Fix ClangImporter imported decls verification.
>- *edit*: lib/ClangImporter/ImporterImpl.h
>   - *edit*: lib/ClangImporter/ClangImporter.cpp
>
>- Commit *abb88f94921a962aa19ec39653e62ee05cec48cb* by *jordan_rose:*
>
>[Verifier] Hack: Don't verify loaded modules in SIL mode.
>- *edit*: lib/Sema/TypeChecker.cpp
>
>- Commit *fdbc84f7ec77105b23e2cc8b191112ecd01ba9bb* by *jordan_rose:*
>
>[Importer] Preserve argument labels even for accessors.
>- *edit*: lib/ClangImporter/ImportDecl.cpp
>   - *edit*: lib/ClangImporter/ImporterImpl.h
>   - *edit*: test/ClangImporter/Inputs/custom-modules/ObjCParseExtras.h
>   - *edit*: lib/ClangImporter/ImportType.cpp
>   - *edit*: test/ClangImporter/objc_parse.swift
>
>- Commit *7c8117301aa57ec6cf29d39acb98d1b9f3160f1d* by *github:*
>
>In Swift 3 mode, allow "tuple unsplatting" in certain cases. (#7077)
>- *edit*:
>   
> validation-test/compiler_crashers_fixed/26813-generic-enum-tuple