Re: [swift-dev] [swift-lldb-dev] Switching swift to C++14

[Daniel Dunbar via swift-dev]

> On Dec 19, 2017, at 3:59 PM, Ted Kremenek  wrote:
> 
> 
> 
>> On Dec 19, 2017, at 2:31 PM, Daniel Dunbar > > wrote:
>> 
>> 
>> 
>>> On Dec 19, 2017, at 2:27 PM, Ted Kremenek >> > wrote:
>>> 
>>> Fair enough.
>>> 
>>> We care about swiftc and llbuild building a variety of platforms today — 
>>> FreeBSD, Rasberry Pi, etc.  My impression is that C++14 is generally 
>>> supported by both (a) the mininum versions of the distributions we support 
>>> today and (b) the current versions of the platforms we’d like to expand 
>>> Swift to in the future.  Does that sound right?  I suspect you went through 
>>> the same kind of reasoning with llbuild.
>> 
>> It sounds reasonable, but to be honest I never did an audit of what 
>> platforms supported C++14.
> 
> Interesting.  Was that not a concern when that choice was made for llbuild, 
> or was the context different?

The context was different, primarily. My personal expectation was that C++14 
support would be generally available by the time we needed it on other 
platforms, or if not we would undertake the cost of reverting to C++11 at the 
time it was needed.

 - Daniel

> 
>> 
>> I do think that we could always use the Clang++ we build as part of Swift to 
>> build Swift itself. By that logic, it seems reasonable to expect we could 
>> always have C++14 support, although it does mean that porters would need 
>> modern Clang to support their platform. However, that is likely largely a 
>> prerequisite for Swift to work as well.
> 
> That’s a significant change to make just to get C++14 support guaranteed, and 
> (I believe) would have a non-trivial impact on those using development 
> environments that expect to use the Clang bundled with them to build projects.
> 
>> 
>>  - Daniel
>> 
>>> 
>>> On Dec 19, 2017, 2:23 PM -0800, Daniel Dunbar >> >, wrote:
 It wasn’t changed, it has *always* been C++14 since the day we open 
 sourced it. I only investigated the platforms we officially support 
 (Ubuntu 14.04/15.10 at the time, and macOS 10.10+ IIRC).
 
 - Daniel
 
> On Dec 19, 2017, at 2:21 PM, Ted Kremenek  > wrote:
> 
> Daniel,
> 
> When you changed llbuild to require C++14, what platforms did you take 
> into account with that change? If you have already done the assessment 
> here it could speed a resolution of a decision.
> 
> Thanks,
> Ted
> 
>> On Dec 13, 2017, at 3:19 PM, Daniel Dunbar via swift-lldb-dev 
>> > wrote:
>> 
>> FWIW, llbuild requires C++14.
>> 
>> We have to do some minor shenanigans to workaround bugs in libstdc++ on 
>> 14.04, and our use is probably minimal, but just throwing that out there.
>> 
>> - Daniel
>> 
>>> On Dec 13, 2017, at 1:45 PM, Jordan Rose via swift-lldb-dev 
>>> > wrote:
>>> 
>>> No one else has commented on this yet today, so I'll put in that I 
>>> don't have any objections to this and don't foresee any major problems. 
>>> The one place where we'd need to be careful is with LLDB, which imports 
>>> Swift headers; if Swift is going to move to C++14, then Swift-LLDB 
>>> probably has to as well. LLDB folks, what do you think?
>>> 
>>> The other thing to check is if our minimum Clang or libstdc++ 
>>> requirements on Linux didn't support C++14. It looks like our README is 
>>> vague on that, but LLDB already suggests a minimum requirement of Clang 
>>> 3.5, which is new enough. I suspect we're okay here.
>>> 
>>> Jordan
>>> 
>>> 
 On Dec 13, 2017, at 10:36, Saleem Abdulrasool via swift-dev 
 > wrote:
 
 Hi,
 
 The newer Windows SDK requires the use of C++14 (the SDK headers use 
 `auto` return types without trailing type information). Joe mentioned 
 that there was some interest in switching the rest of swift to C++14 
 as well. I figured that I would just start a thread here to determine 
 if this is okay to do globally rather than just specifically for the 
 Windows builds to ensure that we can build the Windows components.
 
 Thanks.
 
 --
 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-lldb-dev] Switching swift to C++14

[Daniel Dunbar via swift-dev]

> On Dec 19, 2017, at 2:27 PM, Ted Kremenek  wrote:
> 
> Fair enough.
> 
> We care about swiftc and llbuild building a variety of platforms today — 
> FreeBSD, Rasberry Pi, etc.  My impression is that C++14 is generally 
> supported by both (a) the mininum versions of the distributions we support 
> today and (b) the current versions of the platforms we’d like to expand Swift 
> to in the future.  Does that sound right?  I suspect you went through the 
> same kind of reasoning with llbuild.

It sounds reasonable, but to be honest I never did an audit of what platforms 
supported C++14.

I do think that we could always use the Clang++ we build as part of Swift to 
build Swift itself. By that logic, it seems reasonable to expect we could 
always have C++14 support, although it does mean that porters would need modern 
Clang to support their platform. However, that is likely largely a prerequisite 
for Swift to work as well.

 - Daniel

> 
> On Dec 19, 2017, 2:23 PM -0800, Daniel Dunbar , 
> wrote:
>> It wasn’t changed, it has *always* been C++14 since the day we open sourced 
>> it. I only investigated the platforms we officially support (Ubuntu 
>> 14.04/15.10 at the time, and macOS 10.10+ IIRC).
>> 
>> - Daniel
>> 
>>> On Dec 19, 2017, at 2:21 PM, Ted Kremenek  wrote:
>>> 
>>> Daniel,
>>> 
>>> When you changed llbuild to require C++14, what platforms did you take into 
>>> account with that change? If you have already done the assessment here it 
>>> could speed a resolution of a decision.
>>> 
>>> Thanks,
>>> Ted
>>> 
 On Dec 13, 2017, at 3:19 PM, Daniel Dunbar via swift-lldb-dev 
  wrote:
 
 FWIW, llbuild requires C++14.
 
 We have to do some minor shenanigans to workaround bugs in libstdc++ on 
 14.04, and our use is probably minimal, but just throwing that out there.
 
 - Daniel
 
> On Dec 13, 2017, at 1:45 PM, Jordan Rose via swift-lldb-dev 
>  wrote:
> 
> No one else has commented on this yet today, so I'll put in that I don't 
> have any objections to this and don't foresee any major problems. The one 
> place where we'd need to be careful is with LLDB, which imports Swift 
> headers; if Swift is going to move to C++14, then Swift-LLDB probably has 
> to as well. LLDB folks, what do you think?
> 
> The other thing to check is if our minimum Clang or libstdc++ 
> requirements on Linux didn't support C++14. It looks like our README is 
> vague on that, but LLDB already suggests a minimum requirement of Clang 
> 3.5, which is new enough. I suspect we're okay here.
> 
> Jordan
> 
> 
>> On Dec 13, 2017, at 10:36, Saleem Abdulrasool via swift-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> The newer Windows SDK requires the use of C++14 (the SDK headers use 
>> `auto` return types without trailing type information). Joe mentioned 
>> that there was some interest in switching the rest of swift to C++14 as 
>> well. I figured that I would just start a thread here to determine if 
>> this is okay to do globally rather than just specifically for the 
>> Windows builds to ensure that we can build the Windows components.
>> 
>> Thanks.
>> 
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> ___
> swift-lldb-dev mailing list
> swift-lldb-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-lldb-dev
 
 ___
 swift-lldb-dev mailing list
 swift-lldb-...@swift.org
 https://lists.swift.org/mailman/listinfo/swift-lldb-dev
>>> 
>> 

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

Re: [swift-dev] [swift-lldb-dev] Switching swift to C++14

[Daniel Dunbar via swift-dev]

It wasn’t changed, it has *always* been C++14 since the day we open sourced it. 
I only investigated the platforms we officially support (Ubuntu 14.04/15.10 at 
the time, and macOS 10.10+ IIRC).

 - Daniel

> On Dec 19, 2017, at 2:21 PM, Ted Kremenek  wrote:
> 
> Daniel,
> 
> When you changed llbuild to require C++14, what platforms did you take into 
> account with that change?  If you have already done the assessment here it 
> could speed a resolution of a decision.
> 
> Thanks,
> Ted
> 
>> On Dec 13, 2017, at 3:19 PM, Daniel Dunbar via swift-lldb-dev 
>>  wrote:
>> 
>> FWIW, llbuild requires C++14.
>> 
>> We have to do some minor shenanigans to workaround bugs in libstdc++ on 
>> 14.04, and our use is probably minimal, but just throwing that out there.
>> 
>> - Daniel
>> 
>>> On Dec 13, 2017, at 1:45 PM, Jordan Rose via swift-lldb-dev 
>>>  wrote:
>>> 
>>> No one else has commented on this yet today, so I'll put in that I don't 
>>> have any objections to this and don't foresee any major problems. The one 
>>> place where we'd need to be careful is with LLDB, which imports Swift 
>>> headers; if Swift is going to move to C++14, then Swift-LLDB probably has 
>>> to as well. LLDB folks, what do you think?
>>> 
>>> The other thing to check is if our minimum Clang or libstdc++ requirements 
>>> on Linux didn't support C++14. It looks like our README is vague on that, 
>>> but LLDB already suggests a minimum requirement of Clang 3.5, which is new 
>>> enough. I suspect we're okay here.
>>> 
>>> Jordan
>>> 
>>> 
 On Dec 13, 2017, at 10:36, Saleem Abdulrasool via swift-dev 
  wrote:
 
 Hi,
 
 The newer Windows SDK requires the use of C++14 (the SDK headers use 
 `auto` return types without trailing type information).  Joe mentioned 
 that there was some interest in switching the rest of swift to C++14 as 
 well.  I figured that I would just start a thread here to determine if 
 this is okay to do globally rather than just specifically for the Windows 
 builds to ensure that we can build the Windows components.
 
 Thanks.
 
 -- 
 Saleem Abdulrasool
 compnerd (at) compnerd (dot) org
 ___
 swift-dev mailing list
 swift-dev@swift.org
 https://lists.swift.org/mailman/listinfo/swift-dev
>>> 
>>> ___
>>> swift-lldb-dev mailing list
>>> swift-lldb-...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev
>> 
>> ___
>> swift-lldb-dev mailing list
>> swift-lldb-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev
> 

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

Re: [swift-dev] [swift-lldb-dev] Switching swift to C++14

[Daniel Dunbar via swift-dev]

FWIW, llbuild requires C++14.

We have to do some minor shenanigans to workaround bugs in libstdc++ on 14.04, 
and our use is probably minimal, but just throwing that out there.

 - Daniel

> On Dec 13, 2017, at 1:45 PM, Jordan Rose via swift-lldb-dev 
>  wrote:
> 
> No one else has commented on this yet today, so I'll put in that I don't have 
> any objections to this and don't foresee any major problems. The one place 
> where we'd need to be careful is with LLDB, which imports Swift headers; if 
> Swift is going to move to C++14, then Swift-LLDB probably has to as well. 
> LLDB folks, what do you think?
> 
> The other thing to check is if our minimum Clang or libstdc++ requirements on 
> Linux didn't support C++14. It looks like our README is vague on that, but 
> LLDB already suggests a minimum requirement of Clang 3.5, which is new 
> enough. I suspect we're okay here.
> 
> Jordan
> 
> 
>> On Dec 13, 2017, at 10:36, Saleem Abdulrasool via swift-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> The newer Windows SDK requires the use of C++14 (the SDK headers use `auto` 
>> return types without trailing type information).  Joe mentioned that there 
>> was some interest in switching the rest of swift to C++14 as well.  I 
>> figured that I would just start a thread here to determine if this is okay 
>> to do globally rather than just specifically for the Windows builds to 
>> ensure that we can build the Windows components.
>> 
>> Thanks.
>> 
>> -- 
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> ___
> swift-lldb-dev mailing list
> swift-lldb-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-lldb-dev

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

Re: [swift-dev] Zero-cost 'Service Provider Interface'/Signature Packages

[Daniel Dunbar via swift-dev]

> On Nov 8, 2017, at 5:27 PM, Johannes Weiß  wrote:
> 
> Hi Daniel,
> 
>> On 2 Nov 2017, at 8:15 pm, Daniel Dunbar  wrote:
>> 
>> My personal preference is to:
>> 1. Do nothing for now, but encourage publishing standardized protocols to 
>> solve this need.
>> 2. Hope for a future with WMO+LTO magic which recovers the performance, for 
>> the case where the entire application ends up using one implementation.
> 
> Hmm, but that'll only work if we get 'whole product optimisation', right? If 
> we still compile one module at the time I don't think the compiler will be 
> able to figure out that there's just one implementation of that protocol in 
> the whole program. In fact it can't as that module might be linked into 
> different programs and one of those programs might have a second 
> implementation of that protocol. This is extremely likely as the 'test 
> program' might have a mock/fake or some special implementation. Did I 
> misunderstand you here?

That’s correct, that is what I meant by magic WMO+LTO future.

>> You can manage some of the “dependency injection” part by making the package 
>> which exports the common protocol also export a global variable for the 
>> concrete implementation in use (with setters). That could just be a 
>> “pattern” people follow. This wouldn’t be particularly pretty, but it would 
>> mean that intermediate packages could avoid declaring a concrete dependency 
>> on any one implementation, and leave it up to clients to pick.
> 
> hmm, two questions:
> - what would the type of that global variable be? All libraries in the 
> program will need to know and agree on that type

It would be the type of the abstract protocol.

> - sounds like ThreadSanitizer would trap here unless we synchronise it which 
> would make it slow again

Depends on how the protocol is phrased. The global instance could be a type 
which is instantiated and then doesn’t require locking.

An example of what I had in mind (Package.swifts left to the reader):
```
$ find . -name \*.swift -exec printf " %s \n" {} \; -exec cat {} \;
 ./Client/Sources/Client/main.swift 
import Log
import BadLogger

Log.registerLogger(BadLogger.self)
let logger = Log.createLogger()!
logger.log("how quaint")


 ./BadLogger/Sources/BadLogger/BadLogger.swift 
import Log

public struct BadLogger: Logger {
public init() {}
public func log(_ message: String) {
fatalError("logging considered harmful: \(message)")
}
}

 ./Log/Sources/Log/Log.swift 
import Dispatch

public protocol Logger {
// MARK: Logger API

init()
func log(_ message: String)
}

// MARK: Global Registration

private let queue = DispatchQueue(label: "org.awesome.log")
private var theLoggerType: Logger.Type? = nil

public func registerLogger(_ type: Logger.Type) {
queue.sync {
theLoggerType = type
}
}

public func createLogger() -> Logger? {
return queue.sync{ theLoggerType }?.init()
}
```

I’m not saying this is the best solution in the world, but it does work 
currently without requiring new features. I agree there is a (small) 
performance cost, but for most use cases I doubt that is the most important 
consideration.

- Daniel

> 
> 
> -- Johannes
> 
>> - Daniel
>> 
>>> On Nov 2, 2017, at 5:57 PM, Johannes Weiß via swift-dev 
>>>  wrote:
>>> 
>>> Hi swift-dev,
>>> 
>>> I talked to a few people about this problem and we agreed that it is a 
>>> problem and that it needs to be discussed. I didn't quite know where it 
>>> would fit best but let's go with swift-dev, please feel free to tell to 
>>> post it elsewhere if necessary. And apologies for the long mail, couldn't 
>>> come up with a sensible tl;dr...
>>> 
>>> Let me briefly introduce the problem what for the lack of a better name I 
>>> call 'signature package' or 'Service Provider Interface' (SPI) as some 
>>> people from the Java community seem to be calling it 
>>> (https://en.wikipedia.org/wiki/Service_provider_interface). For the rest of 
>>> this email I'll use the term SPI.
>>> 
>>> In a large ecosystem there is a few pieces that many libraries will depend 
>>> on and yet it seems pretty much impossible to standardise exactly one 
>>> implementation. Logging is a very good example as many people have 
>>> different ideas about how logging should and should not work. At the moment 
>>> I guess your best bet is to use your preferred logging API and hope that 
>>> all your other dependencies use the same one. If not you'll likely run into 
>>> annoying problems (different sub-systems logging to different places or 
>>> worse).
>>> 
>>> Also, in a world where some dependencies might be closed source this is an 
>>> even bigger problem as clearly no open-source framework will depend on 
>>> something that's not open-source.
>>> 
>>> 
>>> In Java the way seems to be to standardise on some logging interface (read 
>>> `protocol`) with different 

Re: [swift-dev] Zero-cost 'Service Provider Interface'/Signature Packages

[Daniel Dunbar via swift-dev]

My personal preference is to:
1. Do nothing for now, but encourage publishing standardized protocols to solve 
this need.
2. Hope for a future with WMO+LTO magic which recovers the performance, for the 
case where the entire application ends up using one implementation.

You can manage some of the “dependency injection” part by making the package 
which exports the common protocol also export a global variable for the 
concrete implementation in use (with setters). That could just be a “pattern” 
people follow. This wouldn’t be particularly pretty, but it would mean that 
intermediate packages could avoid declaring a concrete dependency on any one 
implementation, and leave it up to clients to pick.

 - Daniel

> On Nov 2, 2017, at 5:57 PM, Johannes Weiß via swift-dev  
> wrote:
> 
> Hi swift-dev,
> 
> I talked to a few people about this problem and we agreed that it is a 
> problem and that it needs to be discussed. I didn't quite know where it would 
> fit best but let's go with swift-dev, please feel free to tell to post it 
> elsewhere if necessary. And apologies for the long mail, couldn't come up 
> with a sensible tl;dr...
> 
> Let me briefly introduce the problem what for the lack of a better name I 
> call 'signature package' or 'Service Provider Interface' (SPI) as some people 
> from the Java community seem to be calling it 
> (https://en.wikipedia.org/wiki/Service_provider_interface). For the rest of 
> this email I'll use the term SPI.
> 
> In a large ecosystem there is a few pieces that many libraries will depend on 
> and yet it seems pretty much impossible to standardise exactly one 
> implementation. Logging is a very good example as many people have different 
> ideas about how logging should and should not work. At the moment I guess 
> your best bet is to use your preferred logging API and hope that all your 
> other dependencies use the same one. If not you'll likely run into annoying 
> problems (different sub-systems logging to different places or worse).
> 
> Also, in a world where some dependencies might be closed source this is an 
> even bigger problem as clearly no open-source framework will depend on 
> something that's not open-source.
> 
> 
> In Java the way seems to be to standardise on some logging interface (read 
> `protocol`) with different implementations. For logging that'd probably be 
> SLF4J [4]. In Swift:
> 
>let logger: LoggerProtocol = MyFavouriteLoggingFramework(configuration)
> 
> where `LoggerProtocol` comes from some SPI package and 
> `MyFavouriteLoggingFramework` is basically what the name says. And as a 
> general practise, everybody would only use `LoggerProtocol`. Then tomorrow 
> when I'll change my mind replacing `MyFavouriteLoggingFramework` by 
> `BetterFasterLoggingFramework` does the job. With 'dependency injection' this 
> 'logger' is handed through the whole program and there's a good chance of it 
> all working out. The benefits are that everybody just needs to agree on a 
> `protocol` instead of an implementation. 
> 
> In Swift the downside is that this means we're now getting a virtual dispatch 
> and the existential everywhere (which in Java will be optimised away by the 
> JIT). That might not be a huge problem but it might undermine 
> 'CrazyFastLoggingFramework's adoption as we always pay overhead.
> 
> I don't think this problem can be elegantly solved today. What I could make 
> work today (and maybe we could add language/SwiftPM support to facilitate it) 
> is this (⚠️, it's ugly)
> 
> - one SwiftPM package defines the SPI only, the only thing it exports is a 
> `public protocol` called say `_spi_Logger`, no implementation
> - every implementation of that SPI defines a `public struct Logger: 
> _spi_Logger` (yes, they all share the _same_ name)
> - every package that wants to log contains
> 
>#if USE_FOO_LOGGER
>import FooLogger
>#elif USE_BAR_LOGGER
>import BarLogger
>#else
>import BuzLogger
>#endif
> 
>  where 'BuzLogger' is the preferred logging system of this package but if 
> either `USE_FOO_LOGGER` or `USE_BAR_LOGGER` was defined this package is happy 
> to use those as well.
> - `Logger` is always used as the type, it might be provided by different 
> packages though
> - in Package.swift of said package we'll need to define something like this:
> 
> func loggingDependency() -> Package.Dependency {
> #if USE_FOO_LOGGER
> return .package(url: "github.com/./foo.git", ...)
> #elif USE_BAR_LOGGER
> return ...
> #else
> return .package(url: "github.com/./buz.git", ...)
> #endif
> }
> 
>  func loggingDependencyTarget() -> Target.Dependency {
> #if USE_FOO_LOGGER
> return "foo"
> #elif USE_BAR_LOGGER
> return "bar"
> #else
> return "buz"
> #endif
> }
> - in the dependencies array of Package.swift we'll then use 
> `loggingDependency()` and in the target we use 

Re: [swift-dev] deprecating -Ounchecked

[Daniel Dunbar via swift-dev]

I am +1 in general, but I do feel there is a legitimate need for this for a 
very very small subset of code. It would feel unfortunate to need to drop to C 
for that — would an equivalent attribute be an alternative?

 - Daniel

> On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev  
> wrote:
> 
> Hi,
> 
> I’d like to propose to deprecate the -Ounchecked swift optimization mode.
> 
> The -Ounchecked mode actually contradicts one of the main goals of swift: to 
> be a safe language.
> In the past we didn’t see lot of significant performance differences compared 
> to -O (there were some improvements but also some regressions).
> Also, we want to reduce the effort of maintaining too many different 
> optimization modes, especially because we recently added -Osize.
> 
> Deprecating would mean that we map -Ounchecked to -O.
> 
> If you have any comments or concerns, please let me know
> 
> Thanks,
> Erik
> 
> 
> 
> ___
> 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] [stdlib] Error recovery hook #12025

[Daniel Dunbar via swift-dev]

It isn’t clear to me how much value this actually adds in a server domain. 
Inability to recover resources means you may immediate run into deadlocks, for 
example, so any robust server strategy will end up having to still handle that. 
If that machinery has to be in place regardless, why not use it for the 
existing error conditions.

Do you have any thoughts there?

 - Daniel

> On Sep 20, 2017, at 2:55 PM, John Holdsworth via swift-dev 
>  wrote:
> 
> Hello Swift developers,
> 
> I’ve raised a rather speculative PR suggesting a hook be added to stdlib
> that would allow users to experiment with error recovery in their apps.
> 
> https://github.com/apple/swift/pull/12025 
> 
> 
> Ultimately it come down to being able to do something like this:
> 
> do {
> try Fortify.exec {
> var a: String!
> a = a!
> }
> }
> catch {
> NSLog("Caught exception: \(error)")
> }
> 
> This was primarily intended for user in "Swift on the server" but could also
> help avoid crashes in the mobile domain. The rationale and mechanics
> are written up at the following url:
> 
> http://johnholdsworth.com/fortify.html 
> 
> 
> I'll accept this won’t be everybody’s cup of tea but at this stage this is
> only an opt-in facilitating patch. Developers need not subject their apps
> to this approach which requires a separate experimental implementation.
> 
> The recovery is reasonably well behaved except it will not recover 
> objects and system resources used in intermediate frames, It’s not
> as random as something like, for example, trying to cancel a thread.
> 
> The debate about whether apps should try to soldier on when something
> is clearly amiss is a stylistic one about which there will be a spectrum of
> opinions. The arguments weigh more in favour in the server domain.
> 
> John
> 
> ___
> 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] Feature Proposal to improve Mixed Frameworks support

[Daniel Dunbar via swift-dev]

> On Jun 29, 2017, at 4:39 PM, Jordan Rose  wrote:
> 
> 
>> On Jun 29, 2017, at 16:35, Daniel Dunbar > > wrote:
>> 
>> 
>>> On Jun 29, 2017, at 10:43 AM, Jordan Rose via swift-dev 
>>> > wrote:
>>> 
>>> Thanks for following through on this, Gonzalo! (The two of us talked about 
>>> this briefly at WWDC.) My idea was a little less clever than yours: just 
>>> always include the internal members in the main header unless you provide 
>>> the name of a second header to put them in. (I called this flag 
>>> -emit-objc-internal-header-path.) That's not quite as flexible, but does 
>>> remove all the guesswork, at least for generated headers.
>> 
>> Doesn't that mean downstream Obj-C clients get bogus code completion results?
> 
> I’m not sure what you mean by this.

I simply misunderstood what you were proposing -- your comments were 
specifically about using a category to extend; not about adding both members to 
the existing public header.

 - Daniel

> Frameworks will always generate both headers, apps and unit tests will always 
> generate one header. The only problem is if someone custom-builds a library 
> target and is relying on that not including internal decls…which, admittedly, 
> can happen. But the current logic is a patchwork of guesswork.
> 
> 
>> 
>>> I filed a bug to track this work: SR-5221 
>>> .
>> 
>> Cool, this sounds like a nice feature to me, I have heard several complaints 
>> about needing to mark things public unnecessarily.
>> 
>>  - Daniel
>> 
>>> 
>>> Jordan
>>> 
>>> 
 On Jun 29, 2017, at 06:35, Gonzalo Larralde via swift-dev 
 > wrote:
 
 I wanted to bring a few points into attention to discuss potential 
 improvements on Mixed Frameworks support. The current status for Mixed 
 Frameworks present some challenges, one specifically being how the Swift 
 compiler generates the ObjC Interface Header. 
 
 At this moment, there's a detection procedure based on the presence of an 
 entry point definition (either using the main file argument, or 
 @UIApplicationMain). The ObjC Interface Header writer 
 (swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to 
 determine if the minimum accessibility level to be exported is either 
 `internal` (for app targets) or `public` (for framework targets). This can 
 be observed here: 
 https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657
  
 
 
 The result of this is a difference on how default visibility is exposed to 
 ObjC code in the same compilation scope.
 
 Having this initial piece of code:
 
 ```
 public class Test: NSObject {
public foo() {}
func bar() {}
 }
 ```
 
 results on the following Interface Header for Main App targets
 
 -swift.h
 ```
 @interface Test : NSObject
 - (void)foo;
 - (void)bar;
 @end
 ```
 
 and the following for Frameworks
 
 -swift.h
 ```
 @interface Test : NSObject
 - (void)foo;
 @end
 ```
 
 This is clearly correct for the publicly visible interface of the 
 framework, but not quite the expected result for the ObjC code compiled in 
 the same target. In that scenario it would make more sense to me that all 
 the `internal` methods are visible.
 
 A potential solution for this problem is to generate two Interface 
 Headers, one that exports all the `public` and `open` entities and 
 members, and an additional header exposing internal entities and declaring 
 categories to public entities and exposing internal members.
 
 Something like:
 
 -swift-internal.h
 ```
 @interface Test (InternalMembers)
 - (void)bar;
 @end
 ```
 
 After that it'll be Xcode's responsability to create both files, and mark 
 them as Public and Project in the Headers Build Phase.
 
 An initial implementation that I think would make sense in case this 
 solution is accepted could be modifying the signature of 
 `swift::printAsObjC` to require the list of access levels to export as a 
 bitmask instead of just getting the minimum. That will enable the exporter 
 to create the following set of files:
 
 * Internal, Public, Open > -swift.h for app targets
 * Public, Open > -swift.h for framework targets
 * Internal > -swift-internal.h for the internal entities and 
 members on framework targets.
 
 To make this happen a new argument needs to be passed to the compiler 
 call. When it's not passed the default behaviour would remain the same, 
 but when it 

Re: [swift-dev] Feature Proposal to improve Mixed Frameworks support

[Daniel Dunbar via swift-dev]

> On Jun 29, 2017, at 10:43 AM, Jordan Rose via swift-dev  
> wrote:
> 
> Thanks for following through on this, Gonzalo! (The two of us talked about 
> this briefly at WWDC.) My idea was a little less clever than yours: just 
> always include the internal members in the main header unless you provide the 
> name of a second header to put them in. (I called this flag 
> -emit-objc-internal-header-path.) That's not quite as flexible, but does 
> remove all the guesswork, at least for generated headers.

Doesn't that mean downstream Obj-C clients get bogus code completion results?

> I filed a bug to track this work: SR-5221 
> .

Cool, this sounds like a nice feature to me, I have heard several complaints 
about needing to mark things public unnecessarily.

 - Daniel

> 
> Jordan
> 
> 
>> On Jun 29, 2017, at 06:35, Gonzalo Larralde via swift-dev 
>> > wrote:
>> 
>> I wanted to bring a few points into attention to discuss potential 
>> improvements on Mixed Frameworks support. The current status for Mixed 
>> Frameworks present some challenges, one specifically being how the Swift 
>> compiler generates the ObjC Interface Header. 
>> 
>> At this moment, there's a detection procedure based on the presence of an 
>> entry point definition (either using the main file argument, or 
>> @UIApplicationMain). The ObjC Interface Header writer 
>> (swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to determine 
>> if the minimum accessibility level to be exported is either `internal` (for 
>> app targets) or `public` (for framework targets). This can be observed here: 
>> https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657
>>  
>> 
>> 
>> The result of this is a difference on how default visibility is exposed to 
>> ObjC code in the same compilation scope.
>> 
>> Having this initial piece of code:
>> 
>> ```
>> public class Test: NSObject {
>>  public foo() {}
>>  func bar() {}
>> }
>> ```
>> 
>> results on the following Interface Header for Main App targets
>> 
>> -swift.h
>> ```
>> @interface Test : NSObject
>> - (void)foo;
>> - (void)bar;
>> @end
>> ```
>> 
>> and the following for Frameworks
>> 
>> -swift.h
>> ```
>> @interface Test : NSObject
>> - (void)foo;
>> @end
>> ```
>> 
>> This is clearly correct for the publicly visible interface of the framework, 
>> but not quite the expected result for the ObjC code compiled in the same 
>> target. In that scenario it would make more sense to me that all the 
>> `internal` methods are visible.
>> 
>> A potential solution for this problem is to generate two Interface Headers, 
>> one that exports all the `public` and `open` entities and members, and an 
>> additional header exposing internal entities and declaring categories to 
>> public entities and exposing internal members.
>> 
>> Something like:
>> 
>> -swift-internal.h
>> ```
>> @interface Test (InternalMembers)
>> - (void)bar;
>> @end
>> ```
>> 
>> After that it'll be Xcode's responsability to create both files, and mark 
>> them as Public and Project in the Headers Build Phase.
>> 
>> An initial implementation that I think would make sense in case this 
>> solution is accepted could be modifying the signature of 
>> `swift::printAsObjC` to require the list of access levels to export as a 
>> bitmask instead of just getting the minimum. That will enable the exporter 
>> to create the following set of files:
>> 
>> * Internal, Public, Open > -swift.h for app targets
>> * Public, Open > -swift.h for framework targets
>> * Internal > -swift-internal.h for the internal entities and 
>> members on framework targets.
>> 
>> To make this happen a new argument needs to be passed to the compiler call. 
>> When it's not passed the default behaviour would remain the same, but when 
>> it is the behaviour needs to be explicitly defined. One option is to just 
>> get the explicit list of access levels to export (something like 
>> `-export=internal,public,open`) or export levels to be defined (0 for app 
>> targets, 1 for public framework targets and 2 for the internal header 
>> framework targets for example)
>> 
>> I hope this feature proposal is complete enough to properly define the scope 
>> and discuss the viability of a possible solution. Otherwise please let me 
>> know.
>> 
>> Thanks.
>> 
>> --
>> Slds,
>> 
>> Gonzalo.
>> ___
>> 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 mailing list
swift-dev@swift.org

Re: [swift-dev] [swift-build-dev] Cross-compiling Swift to WebAssembly

[Daniel Dunbar via swift-dev]

Hi Nathan,

This is probably best brought up on swift-dev (CC'd), since this is (initially) 
mostly a compiler problem and not related to the build tools (the package 
manager).

 - Daniel

> On Jun 25, 2017, at 4:50 PM, Nathan Gray via swift-build-dev 
>  wrote:
> 
> Hello,
> 
> Is anybody else out there excited by the idea of cross-compiling Swift to 
> WebAssembly?  My impression is that almost all of the pieces are in place and 
> that the remaining challenges are likely build related.  For example, the 
> Clang that ships with Xcode 9 includes support for wasm32 as a compilation 
> target.  Has anybody thought about this or pursued it?
> 
> If you're unfamiliar with WebAssembly take a look at http://webassembly.org 
> .  In essence, they're defining a VM that runs in 
> the browser, and all the major browsers are supporting it.  We're talking 
> about being able to code for the web without Javascript.  Imagine being able 
> to write Swift libraries that could be compiled for iOS, Android, Linux, 
> *and* the web!  It's currently possible with C and C++, and Swift is a 
> promising candidate.
> 
> As I understand it, the first obstacle is getting a version of the Swift 
> standard library that's compiled to llvm bitcode using the "wasm32" target.  
> Does that sound achievable?
> 
> Thanks,
> -Nathan
> 
> -- 
> Functional Programmer, iOS Developer, Surfs Poorly
> http://twitter.com/n8gray 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

___
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.10 (master) #3783

[Daniel Dunbar via swift-dev]

I strongly suspect the answer is no.

+Ankit

 - Daniel

> On May 20, 2017, at 7:43 PM, Joe Shajrawi via swift-dev  
> wrote:
> 
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swiftpm/Tests/CommandsTests/PackageToolTests.swift:75:
>  error: PackageToolTests.testUpdate : XCTAssertEqual failed: ("["1.2.3"]") is 
> not equal to ("["1.2.3", "1.2.4"]") - 
> Test Case 'PackageToolTests.testUpdate' failed (2.066 seconds)
> 
> 
> Argyrios, could your commit be responsible for this?
> 
> Regards,
> —Joe |  |  shajr...@apple.com  | (+1) 
> 408-930-5203
> 
> 
> 
> 
> 
> 
>> On May 20, 2017, at 15:29, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3783]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/3783/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Sat, 20 May 2017 15:04:37 -0700
>> Build duration:  24 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: 9424 test(s), Total: 9424 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 432 test(s), Total: 432 test(s)
>> 
>> Changes
>> 
>> Commit 492ad6e7067cf06fb1dbd456bed0e13e94645445 by Argyrios Kyrtzidis:
>> [index] Fix forward declarations interfering with USR generation of
>> 
>> edit: lib/AST/DeclBase.cpp
>> edit: include/clang/AST/DeclBase.h
>> edit: lib/Index/IndexSymbol.cpp
>> edit: test/Index/Core/external-source-symbol-attr.m
>> edit: lib/Index/USRGeneration.cpp
>> edit: tools/libclang/CIndex.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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #3697

[Daniel Dunbar via swift-dev]

We have some lingering non-determinism in this test, apparently:
   
BuildSystem/BuildSystemTests/BuildSystemTaskTests.cancelAllInQueue FAILED

I'll take a look and/or disable until we get it sorted out.

 - Daniel

> On May 17, 2017, at 10:35 AM, Michael Ilseman  wrote:
> 
> Failure in lldbuild seems unrelated:
> 
> FAIL: llbuild-unit :: 
> BuildSystem/BuildSystemTests/BuildSystemTaskTests.cancelAllInQueue (73 of 157)
>  <> TEST 'llbuild-unit :: 
> BuildSystem/BuildSystemTests/BuildSystemTaskTests.cancelAllInQueue' FAILED 
> 
> *** Error in 
> `/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/llbuild-linux-x86_64/unittests/BuildSystem/BuildSystemTests':
>  free(): invalid next size (fast): 0x01724590 ***
> 
> (wild guess) Daniel, are you familiar with why this might be occurring?
> 
>> On May 17, 2017, at 10:30 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3697]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/3697/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Wed, 17 May 2017 10:18:26 -0700
>> Build duration:  11 min
>> Identified problems:
>> 
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all errors:
>> Indication 1 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 9400 test(s), Total: 9400 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 432 test(s), Total: 432 test(s)
>> 
>> Changes
>> 
>> Commit 1b5862728770c97d8a59ba2d3c535bd8deffa8c8 by Tony Parker:
>> Fix `(nsError as Error).localizedDescription` output (#967)
>> 
>> edit: Foundation/NSError.swift
>> edit: TestFoundation/TestNSError.swift
> 

___
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 (swift 4.0) #399

[Daniel Dunbar via swift-dev]

Should be resolved as of c386b7944cf598d56728d30a41ba3819ca04844e.

 - Daniel

> On May 13, 2017, at 2:23 AM, Daniel Dunbar  wrote:
> 
> On it...
> 
>> On May 13, 2017, at 2:14 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_04 [#399]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-ubuntu-16_04/399/
>>  
>> 
>> Project: oss-swift-4.0-incremental-RA-linux-ubuntu-16_04
>> Date of build:   Sat, 13 May 2017 01:12:22 -0700
>> Build duration:  1 hr 2 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 
>> 
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all errors:
>> Indication 1 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 9360 test(s), Total: 9360 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 417 test(s), Total: 417 test(s)
>> 
>> Changes
>> 
>> Commit 6ad42b384ef16b6ce836e3065da57f7dd888e07f by Daniel Dunbar:
>> Change DB API to find constant key IDs.
>> 
>> edit: include/llbuild/Core/BuildEngine.h
>> edit: unittests/Core/BuildEngineTest.cpp
>> edit: lib/Core/BuildEngine.cpp
>> edit: lib/Core/SQLiteBuildDB.cpp
>> edit: unittests/Core/DepsBuildEngineTest.cpp
>> edit: include/llbuild/Core/BuildDB.h
> 

___
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 (swift 4.0) #399

[Daniel Dunbar via swift-dev]

On it...

> On May 13, 2017, at 2:14 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_04 [#399]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-ubuntu-16_04/399/ 
> 
> Project:  oss-swift-4.0-incremental-RA-linux-ubuntu-16_04
> Date of build:Sat, 13 May 2017 01:12:22 -0700
> Build duration:   1 hr 2 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9360 test(s), Total: 9360 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 417 test(s), Total: 417 test(s)
> 
> Changes
> 
> Commit 6ad42b384ef16b6ce836e3065da57f7dd888e07f by Daniel Dunbar:
> Change DB API to find constant key IDs.
> 
> edit: include/llbuild/Core/BuildEngine.h
> edit: unittests/Core/BuildEngineTest.cpp
> edit: lib/Core/BuildEngine.cpp
> edit: lib/Core/SQLiteBuildDB.cpp
> edit: unittests/Core/DepsBuildEngineTest.cpp
> edit: include/llbuild/Core/BuildDB.h

___
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.10 (master) #3051

[Daniel Dunbar via swift-dev]

This commit can't have broken this.

--
#0 0x0398af08 llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x398af08)
#1 0x0398b646 SignalHandler(int) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x398b646)
#2 0x7feec48de670 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11670)
#3 0x0392dfae getOpenFileImpl(int, llvm::Twine const&, unsigned long, 
unsigned long, long, bool, bool) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x392dfae)
#4 0x0392d9d5 llvm::MemoryBuffer::getFileOrSTDIN(llvm::Twine const&, 
long, bool) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x392d9d5)
#5 0x029d9f9a llvm::object::createBinary(llvm::StringRef) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x29d9f9a)
#6 0x005845c9 swift::performLLVM(swift::IRGenOptions&, 
swift::DiagnosticEngine*, llvm::sys::SmartMutex*, llvm::GlobalVariable*, 
llvm::Module*, llvm::TargetMachine*, swift::version::Version const&, 
llvm::StringRef) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x5845c9)
#7 0x004ac791 swift::performFrontend(llvm::ArrayRef, char 
const*, void*, swift::FrontendObserver*) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x4ac791)
#8 0x00465967 main 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x465967)
#9 0x7feec30043f1 __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x203f1)
#10 0x0046300a _start 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x46300a)
Stack dump:
0.  Program arguments: 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift
 -frontend -target x86_64-unknown-linux-gnu -module-cache-path 
/tmp/swift-testsuite-clang-module-cacheDAy9Ak -c -parse-as-library -module-name 
test -validate-tbd-against-ir 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/test/TBD/protocol.swift
 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/TBD/Output/protocol.swift.script:
 line 1: 23695 Bus error   
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift
 -frontend -target x86_64-unknown-linux-gnu -module-cache-path 
'/tmp/swift-testsuite-clang-module-cacheDAy9Ak' -c -parse-as-library 
-module-name test -validate-tbd-against-ir 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/test/TBD/protocol.swift
--

 - Daniel

> On Apr 15, 2017, at 11:53 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3051]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/3051/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Sat, 15 Apr 2017 23:40:37 -0700
> Build duration:   12 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 1 test(s), Passed: 9193 test(s), Total: 9194 test(s)
> Failed: Swift(linux-x86_64).TBD.protocol.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 416 test(s), Total: 416 test(s)
> 
> Changes
> 
> Commit 1c9d43b0e101c925ddeadbee84a1a031bb18b2c0 by Daniel Dunbar:
> [BuildSystem] Lift errors out of frontend API.
> 
> edit: tests/Examples/buildsystem-capi.llbuild
> edit: examples/c-api/buildsystem/main.c
> edit: lib/Commands/BuildSystemCommand.cpp
> edit: lib/BuildSystem/BuildSystemFrontend.cpp

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

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 14.04 (master) #233

[Daniel Dunbar via swift-dev]

This is already fixed (see newer bot runs).

llbuild actually does use C++14, although it's flaky on the 14.04. :)

 - Daniel

> On Feb 10, 2017, at 9:57 AM, Jordan Rose  wrote:
> 
> Looks like an actual llbuild issue. Hey, Daniel, we're not using C++14 yet!
> 
> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/llbuild/lib/BuildSystem/BuildFile.cpp:863:24:
>  error: no template named 'make_unique' in namespace 'std'; did you mean 
> 'llvm::make_unique'?
> auto description = std::make_unique();
>^~~~
>llvm::make_unique
> 
> Jordan
> 
> 
>> On Feb 9, 2017, at 16:36, no-reply--- via swift-dev > > wrote:
>> 
>> [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#233]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/233/ 
>> 
>> Project: oss-swift-package-linux-ubuntu-14_04
>> Date of build:   Thu, 09 Feb 2017 16:12:19 -0800
>> Build duration:  23 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 
>> 
> 

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

Re: [swift-dev] Fetch prebuilts of the dependencies to reduce build time

[Daniel Dunbar via swift-dev]

Unfortunately there is not an easy way to do this that I know of.

It would be awesome if someone would build a Docker image like this and keep it 
up to date...

 - Daniel

> On Dec 22, 2016, at 9:20 AM, Roberto Perez via swift-dev 
>  wrote:
> 
> Hi there.
> 
> Is there a way to fetch prebuilts of the swift deps like clang or llvm?
> 
> First swift build process is painfully slow on my 2012 Macbook Pro mainly 
> because it takes ages in the llvm/clang build.
> 
> It would be nice to fetch prebuilts of those deps and focus on just build 
> swift itself.
> 
> Thanks!
> Roberto.
> ___
> 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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 - Long Test (master) #410

[Daniel Dunbar via swift-dev]

Link Get
Valid decl has error type!
(parameter "rhs" interface type='T._DisallowMixedSignArithmetic')
0  swift   0x03509878
1  swift   0x03509fb6
2  libpthread.so.0 0x7fbd60741670
3  libc.so.6   0x7fbd5f0847ef gsignal + 159
4  libc.so.6   0x7fbd5f0863ea abort + 362
5  swift   0x00dfb75e
6  swift   0x00df06e2
7  swift   0x00dff7f9
8  swift   0x00e01d2e
9  swift   0x00e0473c
10 swift   0x00dff21f
11 swift   0x00dff114
12 swift   0x00de7562
13 swift   0x00a75c3b
14 swift   0x00abf3e8
15 swift   0x00d8a9f9
16 swift   0x00c208d7
17 swift   0x009953db
18 swift   0x0047d90a
19 swift   0x0043b5e7
20 libc.so.6   0x7fbd5f06f3f1 __libc_start_main + 241
21 swift   0x00438a2a
Stack dump:
0.  Program arguments: 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/swift-linux-x86_64/bin/swift
 -frontend -c 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/swiftpm/Sources/PackageGraph/DependencyResolver.swift
 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/swiftpm/Sources/PackageGraph/PackageGraph.swift
 -primary-file 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/swiftpm/Sources/PackageGraph/PackageGraphLoader.swift
 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/swiftpm/Sources/PackageGraph/RepositoryPackageContainerProvider.swift
 -target x86_64-unknown-linux-gnu -disable-objc-interop -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/swiftpm-linux-x86_64/.bootstrap/modules
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/swiftpm-linux-x86_64/.bootstrap/inc
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/foundation-linux-x86_64/Foundation
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/foundation-linux-x86_64/Foundation/usr/lib/swift/CoreFoundation
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/foundation-linux-x86_64/Foundation/usr/lib/swift
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/libdispatch-linux-x86_64/src
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/swift-corelibs-libdispatch
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/xctest-linux-x86_64
 -Xcc -fblocks -emit-module-doc-path 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/swiftpm-linux-x86_64/.bootstrap/PackageGraph.build/PackageGraphLoader~partial.swiftdoc
 -Onone -parse-as-library -module-name PackageGraph -emit-module-path 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/swiftpm-linux-x86_64/.bootstrap/PackageGraph.build/PackageGraphLoader~partial.swiftmodule
 -emit-dependencies-path 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/swiftpm-linux-x86_64/.bootstrap/PackageGraph.build/PackageGraphLoader.d
 -emit-reference-dependencies-path 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/swiftpm-linux-x86_64/.bootstrap/PackageGraph.build/PackageGraphLoader.swiftdeps
 -o 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/buildbot_incremental/swiftpm-linux-x86_64/.bootstrap/PackageGraph.build/PackageGraphLoader.o
 
1.  While walking into body of '+=' in module 'Swift'
2.  While verifying errors 'rhs' in module 'Swift'
 <>:0: error: unable to execute command: Aborted


 - Daniel

> On Dec 22, 2016, at 9:11 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10-long-test [#410]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/410/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10-long-test
> Date of build:Thu, 22 Dec 2016 08:52:00 -0800
> Build duration:   19 min
> Identified problems:
> 
> Compile 

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

[Daniel Dunbar via swift-dev]

Thanks Mishal!

+ Mirza

I reverted in:
  b68d158
while we investigate.

 - Daniel

> On Dec 19, 2016, at 8:56 PM, mishal_shah via swift-dev  
> wrote:
> 
> llbuild test failure:
> 
>  TEST 'llbuild-unit :: 
> BuildSystem/BuildSystemTests/BuildSystemFrontendTest.commandSkippingFailure' 
> FAILED 
> 
> Note: Google Test filter = BuildSystemFrontendTest.commandSkippingFailure
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from BuildSystemFrontendTest
> [ RUN  ] BuildSystemFrontendTest.commandSkippingFailure
> 
> 
> Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
> Testing Time: 10.61s
> 
> Failing Tests (1):
> llbuild-unit :: 
> BuildSystem/BuildSystemTests/BuildSystemFrontendTest.commandSkippingFailure
> 
> Thanks, 
> Mishal Shah
>> On Dec 20, 2016, at 10:24 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#1118]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/1118/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_04
>> Date of build:   Mon, 19 Dec 2016 20:24:28 -0800
>> Build duration:  30 min
>> Identified problems:
>> 
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all errors:
>> Indication 1 
>> 
>> Tests: 
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8673 test(s), Total: 8673 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 237 test(s), Total: 237 test(s)
>> 
>> Changes
>> 
>> Commit a8a0667f50bf0d03bfb68bcaa961f927a8dba153 by hughbellars:
>> Fix MSVC errors compiling GenericSignature.h
>> 
>> edit: include/swift/AST/Type.h
>> edit: include/swift/AST/GenericSignature.h
> 
> ___
> 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 Failure: 0. OSS - Swift Incremental RA - OS X (master) #7287

[Daniel Dunbar via swift-dev]

[xUnit] [INFO] - Processing JUnit
ERROR: Step ‘Publish xUnit test result report’ aborted due to exception: 
java.io.IOException 
: remote 
file operation failed: 
/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx at 
hudson.remoting.Channel@6f4e927a:macOS-02: 
hudson.remoting.ChannelClosedException: channel is already closed
at hudson.FilePath.act(FilePath.java:986) 

at hudson.FilePath.act(FilePath.java:968) 

at 
org.jenkinsci.plugins.xunit.XUnitProcessor.performTests(XUnitProcessor.java:138)
 

at 
org.jenkinsci.plugins.xunit.XUnitProcessor.performXUnit(XUnitProcessor.java:81) 

at 
org.jenkinsci.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:112) 

at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 

at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
 

at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:723)
 

at hudson.model.Build$BuildExecution.post2(Build.java:185) 

at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:668) 

at hudson.model.Run.execute(Run.java:1763) 

at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 

at hudson.model.ResourceController.execute(ResourceController.java:98) 

at hudson.model.Executor.run(Executor.java:410) 

Caused by: hudson.remoting.ChannelClosedException 
:
 channel is already closed
at hudson.remoting.Channel.send(Channel.java:578) 

at hudson.remoting.Request.call(Request.java:130) 

at hudson.remoting.Channel.call(Channel.java:780) 

at hudson.FilePath.act(FilePath.java:979) 

... 13 more
Caused by: java.io.IOException
 at 
hudson.remoting.Channel.close(Channel.java:1163) 

at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:118) 

at hudson.remoting.PingThread.ping(PingThread.java:126) 

at hudson.remoting.PingThread.run(PingThread.java:85) 

Caused by: java.util.concurrent.TimeoutException 
:
 Ping started at 1479593839927 hasn't completed by 1479594079927
... 2 more

Mishal, would it be possible for Swift CI to filter out Java exceptions and 
only send them to the CI team?

 - Daniel

> On Nov 19, 2016, at 2:23 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#7287]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/7287/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Sat, 19 Nov 2016 

Re: [swift-dev] Cleaning up stale branches?

[Daniel Dunbar via swift-dev]

> On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> on Fri Oct 21 2016, John McCall  > wrote:
> 
>>> On Oct 21, 2016, at 10:39 AM, Dave Abrahams via swift-dev 
>>>  wrote:
>>> on Fri Oct 21 2016, Daniel Dunbar  wrote:
>>> 
 While on this topic...
 
>> 
 GitHub's support for doing cross-repo pull requests is
 excellent. Anyone can easily fork the main repo, and push to their
 side repo (for example, with: `git push ddunbar
 HEAD:name-of-my-new-branch`) and the GitHub web UI on the main repo
 will automatically show you a handy button for creating the PR.
 
 With this level of support, IMHO branches usually should be pushed to
 individual's own repos, not the main repo.
>>> 
>>> IMO it depends whether you think Swift development should be
>>> discoverable.  When the Swift project formally engages in developing
>>> something like the new integer and floating point models, there's an
>>> advantage to having it in the main repository.
>> 
>> I don't understand this argument.  Looking at a list of branches is not a 
>> useful
>> way of discovering development history — you don't know which branches are
>> still active, which branches were merged, or which branches were completely
>> abandoned.  
> 
> True.  Maybe discoverability isn't the word I was looking for.  When
> three people want to collaborate on development of a feature branch,
> where should it live?

I agree... longer lived high profile branches make sense to me personally, just 
not short lived "push for purpose of PRing immediately" ones.

 - Daniel

> 
>> Moreover, branches are just commit histories and so are missing all
>> sorts of useful discussion and review that are just as much a part of
>> the development history.  All of these disadvantages are addressed by
>> instead looking at pull requests, and once you're looking at a pull
>> request, it does not matter what repository it came from.
> 
> Sure, OK.  I feel a bit odd about doing development for the project that
> employs me in a “personal fork” of the main repository, but I can
> adjust, if that's what we decide we want to do.
> 
> -- 
> -Dave
> ___
> 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] Cleaning up stale branches?

[Daniel Dunbar via swift-dev]

> On Oct 21, 2016, at 9:57 AM, Mark Lacey <mark.la...@apple.com> wrote:
> 
> 
>> On Oct 21, 2016, at 9:14 AM, Daniel Dunbar via swift-dev 
>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>> 
>> While on this topic...
>> 
>> GitHub's support for doing cross-repo pull requests is excellent. Anyone can 
>> easily fork the main repo, and push to their side repo (for example, with: 
>> `git push ddunbar HEAD:name-of-my-new-branch`) and the GitHub web UI on the 
>> main repo will automatically show you a handy button for creating the PR.
> 
> You can also set the pushurl for a remote so that it goes to a different 
> repo. This is what I do:
> $ git remote -v
> origing...@github.com <mailto:g...@github.com>:apple/swift.git (fetch)
> origing...@github.com <mailto:g...@github.com>:rudkx/swift.git (push)
> 
> This makes it possible to continue using ./utils/update-checkout to set up 
> and update repos, with the one small step that you need to use ‘git config’ 
> to set the pushurl after the initial clone.

Nice, thanks!

 - Daniel

> 
> Any ‘push’ thereafter will go to your fork.
> 
> The only minor annoyance I’ve run across is that ‘git fetch --prune’ and ‘git 
> remote update --prune’ will delete tracking branches for things you push to 
> your fork.
> 
>> With this level of support, IMHO branches usually should be pushed to 
>> individual's own repos, not the main repo.
> 
> I agree. This is how I’ve done all my PRs.
> 
> Mark
> 
> 
>> 
>>  - Daniel
>> 
>>> On Oct 21, 2016, at 5:50 AM, Alex Blewitt via swift-dev 
>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>> 
>>> There are a lot of branches in the main Swift Git repository at the moment. 
>>> Many of these appear to be short-term testing branches that are out of 
>>> date, or work in progress that may be better in an external repository 
>>> until the work is done. There are also a number of branches (e.g. 
>>> swift-3.0-preview-*-branch) which are in most cases out-of-step with the 
>>> tags due to updating version numbers e.g.
>>> 
>>> 9cf1a6f807dd0d36eca20433341a4f1667616431 tag:swift-3.0-PREVIEW-5
>>> b687a0a9d3a4b588ee6c8ca5b43042bbd2fb8586 head:swift-3.0-preview-5-branch
>>> 
>>> Cleaning up the stale branches will allow others to focus on what the 
>>> current work areas are, and what are the main branches to be pushing 
>>> changes to.
>>> 
>>> $ git ls-remote --heads | cut -b-33 | xargs -n 1 git show -s --oneline 
>>> "--pretty=format:%d %ar"
>>> From https://github.com/apple/swift <https://github.com/apple/swift>
>>>  (origin/SR-2545) 7 weeks ago
>>>  (origin/_fastCStringContents) 4 months ago
>>>  (origin/dabrahams-patch-1) 3 months ago
>>>  (origin/dabrahams-patch-3) 8 days ago
>>>  (origin/disable-associated-type-witness-inference) 4 months ago
>>>  (origin/distributed-test) 7 weeks ago
>>>  (origin/dwa-misc) 3 days ago
>>>  (origin/eager-bridging) 8 weeks ago
>>>  (origin/expression-breakup) 10 days ago
>>>  (origin/external-swift-stdlib) 4 weeks ago
>>>  (origin/inhibit-implicit-conversions) 6 months ago
>>>  (origin/jtbandes-patch-1) 5 weeks ago
>>>  (origin/line-directive-maintenance) 4 weeks ago
>>>  (origin/master, origin/HEAD) 10 hours ago
>>>  (origin/master-next) 2 days ago
>>>  (origin/moredistcc) 35 hours ago
>>>  (origin/new-integer-protocols) 15 hours ago
>>>  (origin/non-comparable-indices) 4 months ago
>>>  (origin/revert-5309-overlays-and-silgen_name) 2 days ago
>>>  (origin/rst-to-markdown) 5 months ago
>>>  (origin/runtime-fix-swift-error-box-comparison) 5 weeks ago
>>>  (origin/silgen-tests-should-build-modules) 7 weeks ago
>>>  (origin/stdlib-BidirectionalCollection.removeLast) 5 weeks ago
>>>  (origin/stdlib-default-RangeReplaceableCollection.SubSequence-3.0) 5 weeks 
>>> ago
>>>  (origin/stdlib-indexing) 5 weeks ago
>>>  (tag: swift-2.2.1-SNAPSHOT-2016-04-23-a, origin/swift-2.2-branch) 6 months 
>>> ago
>>>  (origin/swift-2.2-with-migration-attributes) 4 weeks ago
>>>  (origin/swift-2.3-branch) 9 weeks ago
>>>  (origin/swift-3-indexing-model-typechecker-bug-1) 7 months ago
>>>  (origin/swift-3.0-branch) 13 hours ago
>>>  (origin/swift-3.0-preview-1-branch) 4 months ago
>>>  (origin/swift-3.0-preview-2-branch) 4 months ago
>>>  (origin/swift-3.0-preview-3-branch) 3 mont

Re: [swift-dev] Cleaning up stale branches?

[Daniel Dunbar via swift-dev]

While on this topic...

GitHub's support for doing cross-repo pull requests is excellent. Anyone can 
easily fork the main repo, and push to their side repo (for example, with: `git 
push ddunbar HEAD:name-of-my-new-branch`) and the GitHub web UI on the main 
repo will automatically show you a handy button for creating the PR.

With this level of support, IMHO branches usually should be pushed to 
individual's own repos, not the main repo.

 - Daniel

> On Oct 21, 2016, at 5:50 AM, Alex Blewitt via swift-dev  
> wrote:
> 
> There are a lot of branches in the main Swift Git repository at the moment. 
> Many of these appear to be short-term testing branches that are out of date, 
> or work in progress that may be better in an external repository until the 
> work is done. There are also a number of branches (e.g. 
> swift-3.0-preview-*-branch) which are in most cases out-of-step with the tags 
> due to updating version numbers e.g.
> 
> 9cf1a6f807dd0d36eca20433341a4f1667616431 tag:swift-3.0-PREVIEW-5
> b687a0a9d3a4b588ee6c8ca5b43042bbd2fb8586 head:swift-3.0-preview-5-branch
> 
> Cleaning up the stale branches will allow others to focus on what the current 
> work areas are, and what are the main branches to be pushing changes to.
> 
> $ git ls-remote --heads | cut -b-33 | xargs -n 1 git show -s --oneline 
> "--pretty=format:%d %ar"
> From https://github.com/apple/swift 
>  (origin/SR-2545) 7 weeks ago
>  (origin/_fastCStringContents) 4 months ago
>  (origin/dabrahams-patch-1) 3 months ago
>  (origin/dabrahams-patch-3) 8 days ago
>  (origin/disable-associated-type-witness-inference) 4 months ago
>  (origin/distributed-test) 7 weeks ago
>  (origin/dwa-misc) 3 days ago
>  (origin/eager-bridging) 8 weeks ago
>  (origin/expression-breakup) 10 days ago
>  (origin/external-swift-stdlib) 4 weeks ago
>  (origin/inhibit-implicit-conversions) 6 months ago
>  (origin/jtbandes-patch-1) 5 weeks ago
>  (origin/line-directive-maintenance) 4 weeks ago
>  (origin/master, origin/HEAD) 10 hours ago
>  (origin/master-next) 2 days ago
>  (origin/moredistcc) 35 hours ago
>  (origin/new-integer-protocols) 15 hours ago
>  (origin/non-comparable-indices) 4 months ago
>  (origin/revert-5309-overlays-and-silgen_name) 2 days ago
>  (origin/rst-to-markdown) 5 months ago
>  (origin/runtime-fix-swift-error-box-comparison) 5 weeks ago
>  (origin/silgen-tests-should-build-modules) 7 weeks ago
>  (origin/stdlib-BidirectionalCollection.removeLast) 5 weeks ago
>  (origin/stdlib-default-RangeReplaceableCollection.SubSequence-3.0) 5 weeks 
> ago
>  (origin/stdlib-indexing) 5 weeks ago
>  (tag: swift-2.2.1-SNAPSHOT-2016-04-23-a, origin/swift-2.2-branch) 6 months 
> ago
>  (origin/swift-2.2-with-migration-attributes) 4 weeks ago
>  (origin/swift-2.3-branch) 9 weeks ago
>  (origin/swift-3-indexing-model-typechecker-bug-1) 7 months ago
>  (origin/swift-3.0-branch) 13 hours ago
>  (origin/swift-3.0-preview-1-branch) 4 months ago
>  (origin/swift-3.0-preview-2-branch) 4 months ago
>  (origin/swift-3.0-preview-3-branch) 3 months ago
>  (origin/swift-3.0-preview-4-branch) 3 months ago
>  (origin/swift-3.0-preview-5-branch) 3 months ago
>  (origin/swift-3.0-preview-5-speculative) 3 months ago
>  (origin/swift-3.0.1-preview-2-branch) 4 weeks ago
>  (origin/tests-mkdir-p) 7 weeks ago
>  (origin/underscore-playgroundquicklook) 2 months ago
>  (origin/update-checkout-script-for-2.3) 3 months ago
> 
> ___
> 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

[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] Validating ABI consistency between runtime C++ and standard library Swift code

[Daniel Dunbar via swift-dev]

Can you directly pass arguments to the function crossing the ABI boundary, and 
can you directly access them on the other side? If so, what you can do is 
simply synthesize arguments that cross the full range of the bit-representation 
of the argument types, and validate that you see the same range on the other 
side.

I don't know anything about what this interface looks like so I don't have more 
specific ideas, but if you can give me a little more context I've worked on 
this in the past...

Technically you can't necessarily compare the LLVM IR, since there are ways to 
represent the same ABI call with different #s of IR arguments in corner cases.

 - Daniel

> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev  
> wrote:
> 
> I just tracked down a bug due to C++ code in the Swift runtime code trying to 
> interface with standard library code written in Swift, but getting the ABI 
> slightly wrong and leading to some nasty hard-to-reproduce heisenbugs. While 
> I've narrowed down the bug in this specific case, it seems like this is a 
> potentially continuing source of maintenance bugs, especially as we try to 
> bring up the Swift calling convention in the coming year. I'm wondering if 
> there's anything we could do to help validate that C++ and Swift code in the 
> runtime is correctly interfacing. We could at least check that we're passing 
> the right number of arguments by comparing the LLVM IR of the runtime and 
> stdlib, perhaps, though this would have to be a fuzzy type-level match since 
> Clang and Swift aren't normally going to agree on the exact pointer types of 
> arguments.
> 
> -Joe
> ___
> 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] ccache and/or distcc for swift

[Daniel Dunbar via swift-dev]

Ah, if you are specifically asking about the case of speeding up builds from 
scratch using cached results, that *is* somewhat doable, but it is still true 
that I don't know of an existing system for managing it for you.

I want llbuild + swiftc to grow in the direction of being able to solve that 
problem, but no one is actively working on it. If it is something you were 
interested in contributing to (bearing in mind it is a very large project) or 
just pick up and adopt? Also, is this something you were looking for just in 
the context of Swift, or in the Xcode + Swift context?

 - Daniel

> On Sep 28, 2016, at 2:00 PM, Oscar Bonilla via swift-dev 
>  wrote:
> 
> Primarily many builds from scratch. Specifically for a CI pipeline. That's 
> why I was also wondering about distcc, so the build objects could be cached 
> and shared among many machines.
> 
> -- 
> Oscar Bonilla
> Staff Software Engineer
> Tools Group
> 
> 
> 
> oboni...@linkedin.com 
> linkedin.com/in/ seeob
> 
> On Tue, Sep 27, 2016 at 11:52 AM, Kevin Choi  > wrote:
> Just curious, are there scenarios other than simple local build that you wish 
> to speed up? I don't know if ccache offers much more than incremental build 
> by existing build systems.
> -Kevin
> 
> On Tue, Sep 27, 2016 at 11:09 AM, Oscar Bonilla via swift-dev 
> > wrote:
> Hello swift developers,
> 
> I was wondering if any of you knows anything about something
> like ccache and/or distcc for swift.
> 
> Basically, what I want is to speed up compiles by caching the result
> (like ccache does) and then reusing the compilation results across
> multiple machines.
> 
> Does anything like that exist for swift? I looked at ccache but they
> don't support swift and I couldn't find anything on distcc either.
> 
> Thanks!
> 
> -Oscar
> 
> ___
> 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 mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] ccache and/or distcc for swift

[Daniel Dunbar via swift-dev]

Hi Oscar,

Nothing exists like that for Swift yet -- it is non-trivial for several 
reasons, the big two are:
1. The Swift compilation model relies on global information for a module, and 
needs to see all the sources. This process is currently embedded in the 
`swiftc` driver which would need to be aware of how to manage this process (or 
factored into a library API that a client able to manage the distribution could 
interact with).
2. The Swift compilation model also heavily leverages the ability to import 
Clang modules, which means that it *also* needs to be able to see large amounts 
of C headers, in modular model not a header preprocessing model. The 
distribution mechanism would also need to be aware of this.

 - Daniel

> On Sep 27, 2016, at 11:09 AM, Oscar Bonilla via swift-dev 
>  wrote:
> 
> Hello swift developers,
> 
> I was wondering if any of you knows anything about something
> like ccache and/or distcc for swift.
> 
> Basically, what I want is to speed up compiles by caching the result
> (like ccache does) and then reusing the compilation results across
> multiple machines.
> 
> Does anything like that exist for swift? I looked at ccache but they
> don't support swift and I couldn't find anything on distcc either.
> 
> Thanks!
> 
> -Oscar
> ___
> 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] Major SwiftPM compile time regression

[Daniel Dunbar via swift-dev]

I'm assuming its the type checker based on how it manifests (and we haven't 
changed anything interesting in the module that is slow to build), but I 
haven't looked at any samples.

 - Daniel

> On Sep 24, 2016, at 9:23 PM, Ted Kremenek <kreme...@apple.com> wrote:
> 
> Does this look related to the type checker (I saw Mark’s comments in the SR) 
> or something else?
> 
>> On Sep 24, 2016, at 3:23 PM, Daniel Dunbar via swift-dev 
>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>> 
>> Swift TOT is currently taking a very long time (and upwards of 8GB) to build 
>> SwiftPM. I filed:
>>  https://bugs.swift.org/browse/SR-2754 
>> <https://bugs.swift.org/browse/SR-2754>
>> can someone on the compiler take a look? This makes it hard to develop with 
>> TOT.
>> 
>> - Daniel
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org <mailto: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] Major SwiftPM compile time regression

[Daniel Dunbar via swift-dev]

Swift TOT is currently taking a very long time (and upwards of 8GB) to build 
SwiftPM. I filed:
  https://bugs.swift.org/browse/SR-2754
can someone on the compiler take a look? This makes it hard to develop with TOT.

 - Daniel

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

Re: [swift-dev] Swift Package Manager

[Daniel Dunbar via swift-dev]

Yes, this is intentional.

We don't have a strategy yet for dealing with package-specific individual 
compilation flags like this.

In the meantime, you can try using a system module package instead, and 
manually defining OPENSSL_LOAD_CONF inside a header within the system module 
package before you import the actual OpenSSL headers.

 - Daniel

> On Sep 20, 2016, at 1:35 PM, Raminder Sodhi via swift-dev 
>  wrote:
> 
> Hi,
>  
> The swift package manger seems consider the -DOPENSSL_LOAD_CONF as a 
> non-whitelisted flag.
> As a result, I get
> nonWhitelistedFlags("Non whitelisted flags found: [\"-DOPENSSL_LOAD_CONF\"] 
> in pc file openssl")
>  
> Is this flag supposed to be non whitelisted ?
>  
> Seems relevant to be by reading upon this:
> https://wiki.openssl.org/index.php/Library_Initialization#OPENSSL_config 
> 
>  
>  
> Raminder Sodhi
> E-mail: sodra...@ca.ibm.com 
> ___
> 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] Llvm Toolchain packaging

[Daniel Dunbar via swift-dev]

I don't think it is documented anywhere, but it is embedded in Swift's 
utils/build-script-impl.

 - Daniel

> On Aug 19, 2016, at 2:49 PM, Patrice Kouame  wrote:
> 
> Excellent!  That did the trick…
> 
> Just out of curiosity, where is that documented?  The trunk llvm plist is an 
> old Info.plist with an odd (dated) structure, I did have to “modernize it 
> along the lines of the default Xcode default one.  Just wondering if there 
> are any other fields I need to set.  Is there a unique swift toolchain 
> packaging “project” I can study to figure all this out on my own?
> 
> Thanks much in advance,  
> 
> Regards, Patrice
>> On Aug 19, 2016, at 5:08 PM, Daniel Dunbar  wrote:
>> 
>> Is CompatibilityVersion set in the LLVM toolchains? IIRC, Xcode 8 requires 
>> it to be 2.
>> 
>> - Daniel
>> 
>>> On Aug 19, 2016, at 1:12 PM, Patrice Kouame via swift-dev 
>>>  wrote:
>>> 
>>> Hi all - Xcode doesn't recognize my llvm toolchain even though it was built 
>>> right out of llvm trunk with llvm toolchain enabled. However, Swift 
>>> toolchains are imported with ease into Xcode. Just by dropping into 
>>> toolchains. I'd like to find out more about how swift manages to package 
>>> their toolchains so that Xcode doesn't complain about incompatibility. 
>>> What's the secret sauce? Can any one point me in the right direction? Is it 
>>> signing related? I'm on a bleeding edge environment with Sierra public beta 
>>> and Xcode 8 beta.
>>> Currently I just change my path to "enable" my preferred clang toolchain, 
>>> but would like to avoid that in the future by switching with xcode-select. 
>>> Any help is greatly appreciated...
>>> 
>>> Patrice
>>> 
>>> ___
>>> 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-lldb-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (master) #1930

[Daniel Dunbar via swift-dev]

> On Aug 19, 2016, at 2:22 PM, Todd Fiala  wrote:
> 
> First off, I think the whole LLDB team can agree on the simple principle that 
> tests that sometimes fail is not something we’re shooting for, so we’re on 
> the same page with the general sentiment.
> 
> But, rather than talking in sweeping generalizations, let’s take this exact 
> failure as an example.  It was a socket attempting to connect.  It uses 
> general socket timeouts.  If it’s using a default, it will typically be 
> something like 30 seconds.  Per my previous comment, this is not something we 
> see fail with any kind of frequency.  We just had a failure on it now.  Is 
> the solution to say we want 35 seconds?  1 minute?  2 minutes?  We’re using 
> end-to-end testing here, and therefore we are subject to how a real system 
> behaves.  If we crank that up, there could be a time where we overload the 
> server further, and the socket facility just fails.  What do you do then, 
> claim the test as unworthy?
> 
> The challenge we run into on LLDB is that, while we do have a growing number 
> of unit tests that are strict input/output verification, far too much of a 
> functioning debugger’s operations are not covered adequately by that.  So we 
> have a large body of end to end tests.  Sometimes those fail under heavy 
> load.  Sometimes those issues are ours - we have hidden races that are only 
> exposed when the machine is grinding to a halt.  Sometimes it is that the OS 
> fails to handle requests for resources that the debugger needs.
> 
> So it isn’t as simple as saying “file a bug to make the LLDB test suite more 
> reliable.”  (I wish it were!)

This is specifically why I proposed a concrete strategy like running a stress 
test of the test suite. That is actionable, and should shake some bugs I would 
hope?

Another actionable strategies (although one I'm not a big fan of) is enhance 
the test suite to automatically re-attempt flaky tests.

> 
> On the positive side, we have more resources going into improving our quality 
> in the upcoming months, and we now have a dedicated quality engineer working 
> with us.  I expect this will help things as we move forward.  And we’re 
> looking to sink some of the system testing that currently exists end-to-end 
> in LLDB to a more input-output style testing that we can do without needing 
> the whole of LLDB (e.g. DWARF verification, DWARF type round-tripping through 
> the compiler, etc. - Greg and Sean can speak more to what we’re doing there).

Great!

 - Daniel

> 
> The net effect is that we should be hitting less of this noise.
> 
> -Todd
> On August 19, 2016 at 2:10:14 PM, Daniel Dunbar via swift-lldb-dev 
> (swift-lldb-...@swift.org ) wrote:
> 
>> The amount of flakiness in the LLDB tests is disturbing... is there a 
>> high-level bug tracking improving this? It seems like it might be worth 
>> running a stress test of the tests on a loaded machine to try and shake out 
>> such problems.
>> 
>>  - Daniel
>> 
>>> On Aug 19, 2016, at 1:58 PM, Todd Fiala via swift-lldb-dev 
>>> > wrote:
>>> 
 
 On Aug 19, 2016, at 1:42 PM, Enrico Granata > wrote:
 
> 
> On Aug 19, 2016, at 11:20 AM, Todd Fiala via swift-lldb-dev 
> > wrote:
> 
> It looks like this may be the packaging build:
> 
>>> 
>>> oss-swift-package-linux-ubuntu-15_10
> 
> It was this build:
> 
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1930/consoleFull#465392916fca400bf-2f4a-462e-b517-e058d770b2d7
>  
> 
> 
> It has since gone blue.
> 
> I don’t think I recall ever seeing that test fail before in an 
> intermittent way, but that might be what happened here.
> 
 
 Given the failure mode, it does sound likely:
 
 
 File "/usr/lib/python2.7/socket.py", line 206, in accept sock, addr
 = self._sock.accept() timeout: timed out
 
 
 
>>> 
>>> If we see that again, we may be able to tweak the socket timeout to allow 
>>> for heavily loaded test CI.
>>> 
> -Todd
> 
>> On Aug 19, 2016, at 11:15 AM, Kate Stone via swift-lldb-dev 
>> > wrote:
>> 
>> Where is this failure being reported?  I’m not seeing anything on 
>> swift-3.0-branch or master on ci.swift.org .
>> 
>> Kate Stone k8st...@apple.com 
>>  Xcode Low Level Tools
>> 
>>> On Aug 19, 2016, at 12:15 AM, mishal_shah via swift-lldb-dev 
>>> > wrote:
>>> 
>>> + 

Re: [swift-dev] [swift-lldb-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (master) #1930

[Daniel Dunbar via swift-dev]

The amount of flakiness in the LLDB tests is disturbing... is there a 
high-level bug tracking improving this? It seems like it might be worth running 
a stress test of the tests on a loaded machine to try and shake out such 
problems.

 - Daniel

> On Aug 19, 2016, at 1:58 PM, Todd Fiala via swift-lldb-dev 
>  wrote:
> 
>> 
>> On Aug 19, 2016, at 1:42 PM, Enrico Granata > > wrote:
>> 
>>> 
>>> On Aug 19, 2016, at 11:20 AM, Todd Fiala via swift-lldb-dev 
>>> > wrote:
>>> 
>>> It looks like this may be the packaging build:
>>> 
> oss-swift-package-linux-ubuntu-15_10
>>> 
>>> It was this build:
>>> 
>>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1930/consoleFull#465392916fca400bf-2f4a-462e-b517-e058d770b2d7
>>>  
>>> 
>>> 
>>> It has since gone blue.
>>> 
>>> I don’t think I recall ever seeing that test fail before in an intermittent 
>>> way, but that might be what happened here.
>>> 
>> 
>> Given the failure mode, it does sound likely:
>> 
>>   File "/usr/lib/python2.7/socket.py", line 206, in accept
>> sock, addr = self._sock.accept()
>> timeout: timed out
>> 
>> 
> 
> If we see that again, we may be able to tweak the socket timeout to allow for 
> heavily loaded test CI.
> 
>>> -Todd
>>> 
 On Aug 19, 2016, at 11:15 AM, Kate Stone via swift-lldb-dev 
 > wrote:
 
 Where is this failure being reported?  I’m not seeing anything on 
 swift-3.0-branch or master on ci.swift.org .
 
 Kate Stone k8st...@apple.com 
  Xcode Low Level Tools
 
> On Aug 19, 2016, at 12:15 AM, mishal_shah via swift-lldb-dev 
> > wrote:
> 
> + swift-lldb-dev group.  
> 
>> On Aug 18, 2016, at 9:47 PM, Daniel Dunbar > > wrote:
>> 
>> Failing in lldb:
>> Command invoked: 
>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/test/dotest.py
>>  --executable 
>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/lldb-linux-x86_64/bin/lldb
>>  --rerun-all-issues -C 
>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/llvm-linux-x86_64/bin/clang
>>  -s 2016-08-18-15_15_07 --results-port 41187 --inferior -p 
>> TestStubReverseConnect.py 
>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test
>>  --event-add-entries worker_index=14:int
>> 
>> Configuration: arch=x86_64 
>> compiler=/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/llvm-linux-x86_64/bin/clang
>> --
>> Collected 2 tests
>> 
>> ==
>> ERROR: test_reverse_connect_works_llgs 
>> (TestStubReverseConnect.TestStubReverseConnect)
>> --
>> Traceback (most recent call last):
>>   File 
>> "/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test/decorators.py",
>>  line 121, in wrapper
>> func(*args, **kwargs)
>>   File 
>> "/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test/decorators.py",
>>  line 121, in wrapper
>> func(*args, **kwargs)
>>   File 
>> "/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubReverseConnect.py",
>>  line 89, in test_reverse_connect_works_llgs
>> self.reverse_connect_works()
>>   File 
>> "/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubReverseConnect.py",
>>  line 67, in reverse_connect_works
>> (stub_socket, address) = self.listener_socket.accept()
>>   File "/usr/lib/python2.7/socket.py", line 206, in accept
>> sock, addr = self._sock.accept()
>> timeout: timed out
>> Config=x86_64-/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9
>> --
>> Ran 2 tests in 22.006s
>> 
>> RESULT: FAILED (0 passes, 0 failures, 1 errors, 1 skipped, 0 expected 
>> failures, 

Re: [swift-dev] Llvm Toolchain packaging

[Daniel Dunbar via swift-dev]

Is CompatibilityVersion set in the LLVM toolchains? IIRC, Xcode 8 requires it 
to be 2.

 - Daniel

> On Aug 19, 2016, at 1:12 PM, Patrice Kouame via swift-dev 
>  wrote:
> 
> Hi all - Xcode doesn't recognize my llvm toolchain even though it was built 
> right out of llvm trunk with llvm toolchain enabled. However, Swift 
> toolchains are imported with ease into Xcode. Just by dropping into 
> toolchains. I'd like to find out more about how swift manages to package 
> their toolchains so that Xcode doesn't complain about incompatibility. What's 
> the secret sauce? Can any one point me in the right direction? Is it signing 
> related? I'm on a bleeding edge environment with Sierra public beta and Xcode 
> 8 beta.
> Currently I just change my path to "enable" my preferred clang toolchain, but 
> would like to avoid that in the future by switching with xcode-select. Any 
> help is greatly appreciated...
> 
> Patrice
> 
> ___
> 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 Failure: OSS - Swift Package - Ubuntu 15.10 (master) #1930

[Daniel Dunbar via swift-dev]

Failing in lldb:
Command invoked: 
/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/test/dotest.py
 --executable 
/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/lldb-linux-x86_64/bin/lldb
 --rerun-all-issues -C 
/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/llvm-linux-x86_64/bin/clang
 -s 2016-08-18-15_15_07 --results-port 41187 --inferior -p 
TestStubReverseConnect.py 
/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test
 --event-add-entries worker_index=14:int

Configuration: arch=x86_64 
compiler=/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/llvm-linux-x86_64/bin/clang
--
Collected 2 tests

==
ERROR: test_reverse_connect_works_llgs 
(TestStubReverseConnect.TestStubReverseConnect)
--
Traceback (most recent call last):
  File 
"/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test/decorators.py",
 line 121, in wrapper
func(*args, **kwargs)
  File 
"/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test/decorators.py",
 line 121, in wrapper
func(*args, **kwargs)
  File 
"/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubReverseConnect.py",
 line 89, in test_reverse_connect_works_llgs
self.reverse_connect_works()
  File 
"/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubReverseConnect.py",
 line 67, in reverse_connect_works
(stub_socket, address) = self.listener_socket.accept()
  File "/usr/lib/python2.7/socket.py", line 206, in accept
sock, addr = self._sock.accept()
timeout: timed out
Config=x86_64-/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9
--
Ran 2 tests in 22.006s

RESULT: FAILED (0 passes, 0 failures, 1 errors, 1 skipped, 0 expected failures, 
0 unexpected successes)
Session logs for test failures/errors/unexpected successes can be found in 
directory '2016-08-18-15_15_07'

 <>[TestStubReverseConnect.py FAILED]
Command invoked: /usr/bin/python 
/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/test/dotest.py
 --executable 
/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/lldb-linux-x86_64/bin/lldb
 --rerun-all-issues -C 
/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/build/buildbot_linux/llvm-linux-x86_64/bin/clang
 -s 2016-08-18-15_15_07 --results-port 41187 --inferior -p 
TestStubReverseConnect.py 
/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15_10/lldb/packages/Python/lldbsuite/test
 --event-add-entries worker_index=14:int

 - Daniel

> On Aug 18, 2016, at 9:18 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1930]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1930/ 
> 
> Project:  oss-swift-package-linux-ubuntu-15_10
> Date of build:Thu, 18 Aug 2016 20:26:52 -0700
> Build duration:   51 min
> Identified problems:
> 
> 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 2ebab526bfd7a5ce6ef460bebee0399fe669612d by xi_ge:
> [FixCode] Apply coercion fixits on return statement and initialization
> 
> edit: test/FixCode/fixits-apply-objc.swift
> edit: test/FixCode/fixits-apply-objc.swift.result
> edit: lib/Sema/CSDiag.cpp
> edit: test/FixCode/fixits-apply.swift.result
> 
> Commit 6447a2d16edcfbceab940d58a321b3ef70525f1a by daniel_dunbar:
> [Basic] Update Thread shim to match changes on Linux side.
> 
> edit: Sources/Basic/Thread.swift

___
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 15.10 (swift 3.0) #106

[Daniel Dunbar via swift-dev]

IMHO you can go ahead and land the revert, it is trivial.

It's unfortunate we don't have a good way to manage this yet -- my suggestion 
would be that when it is ready to land (again) and well tested just land both 
patches in mainline. I realize that is unfortunate, but it is more reliable 
than waiting to land them independently with the @swift-ci lag.

 - Daniel

> On Aug 17, 2016, at 8:01 PM, Greg Parker  wrote:
> 
> #4361 failed its Linux smoke test and never started its OS X test. I'm 
> reverting once I find the right thing to revert. If you want to fix it, work 
> fast.
> 
> 
>> On Aug 17, 2016, at 4:57 PM, Daniel Dunbar > > wrote:
>> 
>> I suspect it is just waiting on:
>>   https://github.com/apple/swift/pull/4361 
>> 
>> to finish testing, which it looks like is close.
>> 
>>  - Daniel
>> 
>>> On Aug 17, 2016, at 4:54 PM, Greg Parker via swift-dev >> > wrote:
>>> 
>>> This is about to break all of the bots. When do you expect a fix?
>>> 
 On Aug 17, 2016, at 4:28 PM, Max Moiseev via swift-dev 
 > wrote:
 
 Unfortunate but expected. Need this change in the SwiftPM in order to test 
 the https://github.com/apple/swift/pull/4361 
 .
 
> On Aug 17, 2016, at 4:22 PM, no-re...@swift.org 
>  wrote:
> 
> [FAILURE] oss-swift-3.0-incremental-RA-linux-ubuntu-15_10 [#106]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/106/
>  
> 
> Project:  oss-swift-3.0-incremental-RA-linux-ubuntu-15_10
> Date of build:Wed, 17 Aug 2016 16:06:24 -0700
> Build duration:   16 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 95e92d5c6cfada9687f9d40822e1c78166e1a752 by jgroff:
> SILGen: Set context generic params for bridging thunks.
> 
> add: test/SILGen/Inputs/objc_bridged_generic_conformance.h
> edit: lib/SILGen/SILGenBridging.cpp
> add: test/SILGen/objc_bridged_generic_conformance.swift
> 
> Commit 9ae709d135597d8421ba34f7d705aa17491890dd by jgroff:
> IRGen: Correctly register conformances for generic ObjC classes.
> 
> edit: lib/IRGen/GenDecl.cpp
> add: test/IRGen/Inputs/objc_bridged_generic_conformance.h
> add: test/IRGen/objc_bridged_generic_conformance.swift
> 
> Commit 5f65fa8594735cc579cd883bc252b0ef601c792d by moiseev:
> Removing the TextOutputStreamable typealias...
> 
> delete: Sources/Basic/SwiftShims.swift
 
 ___
 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 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 15.10 (swift 3.0) #106

[Daniel Dunbar via swift-dev]

I suspect it is just waiting on:
  https://github.com/apple/swift/pull/4361
to finish testing, which it looks like is close.

 - Daniel

> On Aug 17, 2016, at 4:54 PM, Greg Parker via swift-dev  
> wrote:
> 
> This is about to break all of the bots. When do you expect a fix?
> 
>> On Aug 17, 2016, at 4:28 PM, Max Moiseev via swift-dev > > wrote:
>> 
>> Unfortunate but expected. Need this change in the SwiftPM in order to test 
>> the https://github.com/apple/swift/pull/4361 
>> .
>> 
>>> On Aug 17, 2016, at 4:22 PM, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-3.0-incremental-RA-linux-ubuntu-15_10 [#106]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/106/
>>>  
>>> 
>>> Project:oss-swift-3.0-incremental-RA-linux-ubuntu-15_10
>>> Date of build:  Wed, 17 Aug 2016 16:06:24 -0700
>>> Build duration: 16 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 95e92d5c6cfada9687f9d40822e1c78166e1a752 by jgroff:
>>> SILGen: Set context generic params for bridging thunks.
>>> 
>>> add: test/SILGen/Inputs/objc_bridged_generic_conformance.h
>>> edit: lib/SILGen/SILGenBridging.cpp
>>> add: test/SILGen/objc_bridged_generic_conformance.swift
>>> 
>>> Commit 9ae709d135597d8421ba34f7d705aa17491890dd by jgroff:
>>> IRGen: Correctly register conformances for generic ObjC classes.
>>> 
>>> edit: lib/IRGen/GenDecl.cpp
>>> add: test/IRGen/Inputs/objc_bridged_generic_conformance.h
>>> add: test/IRGen/objc_bridged_generic_conformance.swift
>>> 
>>> Commit 5f65fa8594735cc579cd883bc252b0ef601c792d by moiseev:
>>> Removing the TextOutputStreamable typealias...
>>> 
>>> delete: Sources/Basic/SwiftShims.swift
>> 
>> ___
>> 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 mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [swift-build-dev] JIRA workflow: "Resolved" -> "Verify"?

[Daniel Dunbar via swift-dev]

Do we anticipate Verify being used in practice much? 

Would it be better to simplify the workflow and just have a single 
"Resolved/Closed/Done" state? If the originator does test the bug and find it 
isn't fixed, they can reopen.

My guess is not that many people are going to actively look at their JIRA 
account to find bugs that they are supposed to be verifying.

 - Daniel

> On Aug 15, 2016, at 10:08 AM, Jordan Rose via swift-build-dev 
>  wrote:
> 
> Hi, swift-dev et al (but especially Ted). I’ve recently noticed that our JIRA 
> workflow has been a bit confusing. We currently have five “statuses":
> 
> 1. Opened: This bug has been filed.
> 2. In Progress: Someone is actively working on this bug. (Not everyone has 
> been bothering to set this, but it seems reasonable to have.)
> 3. Resolved: A fix has been merged to master.
> 4. Closed: The fix has been verified by the reporter.
> 5. Reopened: The “fix" doesn’t actually fix the reporter’s problem.
> 
> The problem is that the “Resolved” and “Closed” statuses aren’t really 
> distinguished on the site itself—it’s unclear for a contributor which one 
> they’re supposed to use when they get something merged, and it’s unclear for 
> the reporter what they’re supposed to say. Therefore, I suggest changing the 
> “Resolved” status to “Verify” (like we use in Radar) and the “Resolve Issue” 
> button to “Mark Resolved”.
> 
> (There are other things unspecified here, such as how to track what release a 
> fix gets into, or what the story is for the Assignee field, but we can 
> discuss those later.)
> 
> What do you think?
> Thanks,
> Jordan
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-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: OSS - Swift Package - Ubuntu 14.04 (master) #1892

[Daniel Dunbar via swift-dev]

Thanks Tony!

 - Daniel

> On Aug 12, 2016, at 3:34 PM, Tony Parker  wrote:
> 
> This has been failing for too long, so I filed a JIRA and will shortly push a 
> commit to disable the test.
> 
> https://bugs.swift.org/browse/SR-2332 
> 
> - Tony
> 
>> On Aug 12, 2016, at 9:26 AM, Daniel Dunbar > > wrote:
>> 
>> Anyone know who/what is tracking this:
>> 
>> -- Testing: 19 tests, 12 threads --
>> FAIL: SwiftXCTestFunctionalTests :: 
>> Asynchronous/Predicates/Expectations/main.swift (10 of 19)
>>  <> TEST 'SwiftXCTestFunctionalTests :: 
>> Asynchronous/Predicates/Expectations/main.swift' FAILED 
>> Script:
>> --
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
>>  -Xlinker -rpath -Xlinker 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64
>>  -L 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64
>>  -I 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64
>>  -Xlinker -rpath -Xlinker 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation
>>  -L 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation
>>  -I 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation
>>  -I 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation/usr/lib/swift
>>  
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift
>>  -o 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates
>>  > 
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/main.swift.tmp
>>  || true
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker.py
>>  
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/main.swift.tmp
>>  
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift
>> --
>> Exit Code: 1
>> 
>> Command Output (stdout):
>> --
>> Command 0: 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/swift-linux-x86_64/bin/swiftc"
>>  "-Xlinker" "-rpath" "-Xlinker" 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64"
>>  "-L" 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64"
>>  "-I" 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64"
>>  "-Xlinker" "-rpath" "-Xlinker" 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation"
>>  "-L" 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation"
>>  "-I" 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation"
>>  "-I" 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation/usr/lib/swift"
>>  
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift"
>>  "-o" 
>> "/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates"
>> Command 0 Result: 0
>> Command 0 Output:
>> 
>> 
>> Command 0 Stderr:
>> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:23:9:
>>  warning: result of call to 
>> 'expectation(for:evaluatedWith:file:line:handler:)' is unused
>> expectation(for: 

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 14.04 (master) #1892

[Daniel Dunbar via swift-dev]

Anyone know who/what is tracking this:

-- Testing: 19 tests, 12 threads --
FAIL: SwiftXCTestFunctionalTests :: 
Asynchronous/Predicates/Expectations/main.swift (10 of 19)
 <> TEST 'SwiftXCTestFunctionalTests :: 
Asynchronous/Predicates/Expectations/main.swift' FAILED 
Script:
--
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
 -Xlinker -rpath -Xlinker 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64
 -L 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64
 -I 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64
 -Xlinker -rpath -Xlinker 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation
 -L 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation
 -I 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation
 -I 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation/usr/lib/swift
 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift
 -o 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates
 > 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/main.swift.tmp
 || true
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker.py
 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/main.swift.tmp
 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift
--
Exit Code: 1

Command Output (stdout):
--
Command 0: 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/swift-linux-x86_64/bin/swiftc"
 "-Xlinker" "-rpath" "-Xlinker" 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64"
 "-L" 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64"
 "-I" 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/xctest-linux-x86_64"
 "-Xlinker" "-rpath" "-Xlinker" 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation"
 "-L" 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation"
 "-I" 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation"
 "-I" 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/foundation-linux-x86_64/Foundation/usr/lib/swift"
 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift"
 "-o" 
"/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates"
Command 0 Result: 0
Command 0 Output:


Command 0 Stderr:
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:23:9:
 warning: result of call to 'expectation(for:evaluatedWith:file:line:handler:)' 
is unused
expectation(for: predicate, evaluatedWith: object)
^  ~~~
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:33:9:
 warning: result of call to 'expectation(for:evaluatedWith:file:line:handler:)' 
is unused
expectation(for: predicate, evaluatedWith: object)
^  ~~~
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:48:9:
 warning: result of call 

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

[Daniel Dunbar via swift-dev]

Test Case 'TestNSArray.test_sortedArrayUsingComparator' started at 01:54:49.965
TestFoundation: 
/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/include/swift/Runtime/../../../stdlib/public/SwiftShims/RefCount.h:252:
 bool StrongRefCount::doDecrementShouldDeallocate() [ClearPinnedFlag = false]: 
Assertion `newval + quantum >= RC_ONE && "releasing reference with a refcount 
of zero"' failed.

> On Aug 11, 2016, at 1:54 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#6915]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6915/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Thu, 11 Aug 2016 13:19:18 -0700
> Build duration:   35 min
> Tests: 
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8230 test(s), Total: 8230 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit 454ee8a8d9314b33487cb3a5ffd769c6753cc77b by blangmuir:
> [fixcode] Add ( as AnyObject) fixit to the whitelist
> 
> edit: lib/FrontendTool/FrontendTool.cpp
> edit: test/FixCode/fixits-apply.swift
> edit: test/FixCode/fixits-apply.swift.result
> 
> Commit ec539d6abf8aabb747198f41c68cbcde32c28c47 by blangmuir:
> [fixcode] Enabled protocol<...> fixits
> 
> edit: lib/FrontendTool/FrontendTool.cpp
> edit: test/FixCode/fixits-apply.swift.result
> edit: test/FixCode/fixits-apply.swift
> 
> Commit 0bb0c9ea41f26f6d940bb0fc6e66d90a28b21d92 by daniel_dunbar:
> [TestSupport] Add convenience initializers for testing FS instances.
> 
> add: Sources/TestSupport/FileSystemExtensions.swift
> edit: Tests/PackageLoadingTests/ModuleMapGenerationTests.swift
> edit: Tests/PackageLoadingTests/ConventionTests.swift
> 
> Commit 66408be65736ad2dfc314a57a00ed5b91b0b1a99 by daniel_dunbar:
> [TestSupport] Add missing target dependency.
> 
> edit: Package.swift
> 
> Commit fc2157a78765a0b856141d7c7545806033d50b85 by anthony.parker:
> Mark operators in protocols as 'static' [SE-0091] (#522)
> 
> edit: Foundation/NSScanner.swift
> 
> Commit 0821588275e3f7da332214f5fc549a44a69754a1 by github:
> Remove missing test case (#532)
> 
> edit: TestFoundation/TestNSNumber.swift

___
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 14.04 - Long Test (master) #693

[Daniel Dunbar via swift-dev]

Mine, should be fixed in 66408be65736ad2dfc314a57a00ed5b91b0b1a99.

 - Daniel

> On Aug 11, 2016, at 12:50 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#693]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/693/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04-long-test
> Date of build:Thu, 11 Aug 2016 12:34:00 -0700
> Build duration:   16 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 416a36278fffa6e37431b989cd45300c3019920d by vivkong:
> Removing SWIFT_CC annotation in SwiftShims
> 
> edit: stdlib/public/stubs/CommandLine.cpp
> 
> Commit ca009b760424f542bc136dcc186217649fa5 by jordan_rose:
> [PrintAsObjC] Handle forward-declarations for 'Class '.
> 
> edit: lib/PrintAsObjC/PrintAsObjC.cpp
> edit: test/PrintAsObjC/extensions.swift
> edit: test/PrintAsObjC/classes.swift
> 
> Commit 5e06eb28dfa2c991ad428271d066684ad9410f83 by jordan_rose:
> [PrintAsObjC] Assert on types we don't expect in @objc methods.
> 
> edit: lib/PrintAsObjC/PrintAsObjC.cpp
> 
> Commit 8b5f8d1aed6594cbc729aac9f79600a372e07c4f by practicalswift:
> [swiftc (47 vs. 5156)] Add crasher in
> 
> add: 
> validation-test/compiler_crashers/28394-swift-typechecker-checkconformance.swift
> 
> Commit 38e6b2808ee986f9d3a615ebe30e39b772d7887a by github:
> Do even less availability checking under -disable-availability-checking.
> 
> edit: lib/Sema/TypeCheckType.cpp
> edit: lib/Frontend/CompilerInvocation.cpp
> edit: lib/Sema/MiscDiagnostics.cpp
> edit: test/Sema/availability_versions.swift
> edit: tools/sil-opt/SILOpt.cpp
> edit: tools/sil-extract/SILExtract.cpp
> 
> Commit 4201e1b12144d63e26bf580ae4be65c3cb467066 by dabrahams:
> Re-Revert "staging for move to PlaygroundSupport"
> 
> edit: stdlib/public/core/Mirror.swift
> 
> Commit 34b7826cb586b0769ea5f60a7718d7de599ce27f by ankit.spd:
> Remove testDependencies from PackageDescription
> 
> delete: Fixtures/TestDependencies/Complex/TestingLib/TestingLib.swift
> delete: Fixtures/TestDependencies/Simple/Foo/Foo.swift
> delete: Fixtures/TestDependencies/Complex/TestingFooLib/TestingFooLib.swift
> delete: Fixtures/TestDependencies/Complex/App/Package.swift
> delete: Fixtures/TestDependencies/Complex/Foo/Package.swift
> delete: Fixtures/TestDependencies/Simple/TestingLib/TestingLib.swift
> delete: Fixtures/TestDependencies/Complex/TestingLib/Package.swift
> edit: Tests/PackageLoadingTests/SerializationTests.swift
> delete: Fixtures/TestDependencies/Simple/Foo/Package.swift
> edit: Sources/PackageDescription/Package.swift
> delete: Fixtures/TestDependencies/Complex/PrivateFooLib/Package.swift
> delete: Fixtures/TestDependencies/Simple/TestingLib/Package.swift
> edit: Tests/PackageLoadingTests/JSONSerializationTests.swift
> edit: Sources/PackageLoading/JSONSerialization.swift
> edit: Tests/FunctionalTests/MiscellaneousTests.swift
> delete: Fixtures/TestDependencies/Simple/App/main.swift
> edit: Documentation/Reference.md
> delete: Fixtures/TestDependencies/Complex/App/main.swift
> delete: Fixtures/TestDependencies/Simple/App/Package.swift
> delete: Fixtures/TestDependencies/Complex/PrivateFooLib/PrivateFooLib.swift
> edit: Sources/PackageLoading/ManifestLoader.swift
> delete: Fixtures/TestDependencies/Complex/TestingFooLib/Package.swift
> delete: Fixtures/TestDependencies/Complex/Foo/Foo.swift
> 
> Commit 4904faf3be3f8c1b82ba4c00e82134c30f6fdd6b by daniel_dunbar:
> [TestSupport] Move Resources into TestSupport.
> 
> add: Sources/TestSupport/Resources.swift
> edit: Tests/PackageLoadingTests/ManifestTests.swift
> 
> Commit cef8bef3b8a31af18a93c4a0210f46a8549067b6 by lehewjr:
> Build Fix:  _CustomPlaygroundQuickLookable doesn't currently exist on
> 
> edit: Foundation/NSString.swift
> edit: Foundation/NSNumber.swift
> 
> Commit 5050eb64480572d1eaf0f9afeee85baf5c476400 by dabrahams:
> Revert "Moving [Custom]PlaygroundQuickLook[able]"
> 
> edit: TestFoundation/TestNSString.swift
> 
> Commit 1332ea5d6fec9693e0f7dc723b2e41fc06fbbdfb by lehewjr:
> Build Fix: Missed that there was test
> 
> edit: TestFoundation/TestNSNumber.swift
> 
> Commit f71f65e565b0babb22030fe85b7be31c2702d5f8 by github:
> Fix a macOS test failure in TestHTTPCookie. (#523)
> 
> edit: CoreFoundation/Locale.subproj/CFLocale.c
> edit: Foundation/NSDateFormatter.swift
> edit: CoreFoundation/NumberDate.subproj/CFTimeZone.c

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

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 14.04 (master) #1753

[Daniel Dunbar via swift-dev]

This change has already been reverted.

 - Daniel

> On Jul 22, 2016, at 3:02 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#1753]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/1753/ 
> 
> Project:  oss-swift-package-linux-ubuntu-14_04
> Date of build:Fri, 22 Jul 2016 14:17:58 -0700
> Build duration:   44 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 bc94823c363e42583632ce1d5fa7de8ad37c6390 by mark.lacey:
> Use let instead of var in test, and assign to _.
> 
> edit: test/ClangModules/nullability.swift
> 
> Commit 3ba204694e75dcd4dc3e0b7d4413d925b7d58ccb by mark.lacey:
> Do not suppress optional coercion in operators with a nil-literal
> 
> edit: test/expr/cast/nil_value_to_optional.swift
> edit: lib/Sema/ConstraintSystem.h
> edit: test/ClangModules/nullability.swift
> edit: lib/Sema/CSSimplify.cpp
> edit: test/Constraints/diagnostics.swift
> edit: test/ClangModules/objc_failable_inits.swift
> edit: test/expr/expressions.swift
> 
> Commit 51980f7c5fff3dc483eafdae8326d638ee6fa013 by eeckstein:
> SideEffectAnalysis: better selection of what non-returning instructions
> 
> edit: test/SILOptimizer/side-effect.sil
> edit: lib/SILOptimizer/Analysis/SideEffectAnalysis.cpp
> 
> Commit 5f4a8ec8b71595208d09173c074f345489f26149 by aschwaighofer:
> Partial apply forwarder fix for going from single ref counted context to
> 
> edit: test/IRGen/partial_apply_forwarder.sil
> edit: test/IRGen/partial_apply.sil
> edit: lib/IRGen/GenFunc.cpp
> 
> Commit d779c89e6f96ab81dc38f3946dd56d2cb4bd5712 by github:
> [utils] Add swift-xcode-playground-support to checkout script
> 
> edit: utils/update-checkout-config.json
> 
> Commit dd6c5306c14bb2b938d9aa806e193cb3c73ba44d by practicalswift:
> [SourceKit] Add test case for crash triggered in
> 
> add: 
> validation-test/IDE/crashers/075-swift-printoptions-setarchetypeselftransform.swift
> 
> Commit 0c5156da43d3bd506a191a150b238e6e2b01894e by practicalswift:
> [swiftc (69 vs. 5114)] Add crasher in
> 
> add: 
> validation-test/compiler_crashers/28373-swift-printoptions-setarchetypeselftransform.swift
> 
> Commit 8c3b94363446b686446e651c49b9d223721fdccf by github:
> [overlay] Fix PictureInPicture method names with apinotes (#3674)
> 
> edit: apinotes/AVKit.apinotes
> 
> Commit 9b86d583e3da73c6478e31d5b69f782812149821 by jgroff:
> Sema: Allow explicitly bridging anything `as AnyObject`.
> 
> edit: lib/Sema/CSApply.cpp
> edit: lib/Sema/CSSimplify.cpp
> edit: test/Constraints/bridging.swift
> 
> Commit 27a4a8f6b44e0e48864a4dbf24721cd296ebbf25 by jgroff:
> Sema: Metatypes are only representable in ObjC if their instance type is
> 
> edit: lib/AST/Type.cpp
> 
> Commit a41484ea2bf090f4018d32695abbfd6be9a95acd by github:
> Add UnsafeRawPointer type and API. (#3677)
> 
> edit: test/Demangle/Inputs/manglings.txt
> edit: test/IDE/print_stdlib.swift
> edit: lib/Basic/Demangle.cpp
> edit: test/SILOptimizer/specialize.sil
> edit: stdlib/public/core/UnsafePointer.swift.gyb
> edit: test/SILOptimizer/globalredundantloadelimination.sil
> edit: stdlib/public/core/CMakeLists.txt
> edit: include/swift/SIL/SILCloner.h
> add: stdlib/public/core/UnsafeRawPointer.swift.gyb
> edit: docs/ABI.rst
> edit: stdlib/public/core/CTypes.swift
> edit: test/1_stdlib/UnsafePointer.swift.gyb
> add: test/1_stdlib/UnsafeRawPointer.swift
> edit: test/Constraints/diagnostics.swift
> edit: test/Demangle/Inputs/simplified-manglings.txt
> edit: lib/Basic/Remangle.cpp
> edit: test/Constraints/bridging.swift
> edit: test/Constraints/closures.swift
> edit: lib/AST/Mangle.cpp
> edit: stdlib/public/core/GroupInfo.json
> edit: stdlib/public/core/ManagedBuffer.swift
> 
> Commit 618915cbd4c3052364b3e40eb3f166598bafa2b4 by anders:
> Get rid of a comment that no longer applies.
> 
> edit: Sources/Basic/Path.swift
> 
> Commit 11d40205d02121537ce5ec5a7f3d5194ac04c762 by anders:
> Make `pathSeparatorCharacter` be file-private.  In fact, this might be
> 
> edit: Sources/Basic/Path.swift
> 
> Commit 3304dc8133d1101258bd404571c54b1ad5daba91 by ankit.spd:
> [Basic] Add POSIX wrapper for isFile, isDirectory, isSymlink
> 
> add: Tests/Basic/POSIXTests.swift
> edit: Sources/POSIX/stat.swift
> edit: Tests/Basic/XCTestManifests.swift
> edit: Sources/Basic/PathShims.swift
> 
> Commit 22ad1586424d17822faa24429b85d254de332a76 by ankit.spd:
> [Basic] Move FileSystem's exists and isDirectory to POSIX wrapper
> 
> edit: Sources/Basic/FileSystem.swift
> 
> Commit 95e4ae3a60f3dbca657925686becf27c62f58795 by ankit.spd:
> [Basic] Add isFile to FileSystem
> 
> edit: Sources/Basic/FileSystem.swift
> edit: Tests/Basic/FileSystemTests.swift
> 
> 

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - OS X (master) #5221

[Daniel Dunbar via swift-dev]

> On Jul 15, 2016, at 4:10 PM, Philippe Hausler via swift-dev 
>  wrote:
> 
> Hmm that was incomplete:
> 
> Is there a reason why a full toolchain build didn’t pick this up? It seems 
> that when I built locally everything built just fine and tested ok. My 
> configuration that I use to test is a build bot preset that I have modified 
> to have specific destinations such that I can automate installing it.
> 
> I was under the impression that it built swiftpm by default.

I would have expected the buildbot config to, but I don't use the presets 
myself. Passing `--swiftpm` to the build script definitely should.

On a related topic, it would be *very* helpful to us if changes like this could 
land concurrently with the matching support going in on the Linux side, to 
avoid having to add platform specific shims. 

 - Daniel

> 
>> On Jul 15, 2016, at 4:06 PM, Philippe Hausler via swift-dev 
>> > wrote:
>> 
>> NSLock got renamed back to include it’s NS.
>> 
>>> On Jul 15, 2016, at 10:31 AM, Ben Langmuir via swift-dev 
>>> > wrote:
>>> 
>>> These are failing in SwiftPM; and not related to these commits. Did our 
>>> Foundation get out of sync from SwiftPM?
>>> 
>>> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swiftpm/Sources/Basic/Lock.swift:11:14:
>>>  error: no such decl in module
>>> import class Foundation.Lock
>>>  ^  
>>> 
>>> 
>>> 
 On Jul 15, 2016, at 10:28 AM, no-re...@swift.org 
  wrote:
 
 New issue found!
 
 [FAILURE] oss-swift-incremental-RA-osx [#5221]
 
 Build URL: https://ci.swift.org/job/oss-swift-incremental-RA-osx/5221/ 
 
 Project:   oss-swift-incremental-RA-osx
 Date of build: Fri, 15 Jul 2016 10:07:30 -0700
 Build duration:20 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 c25feab0beccadab28d3af23c5ba04e49de13f12 by blangmuir:
 [index] Index system ImportDecls even when there is a DeclarationsOnly
 
 edit: lib/Index/IndexingContext.cpp
 edit: test/Index/index-module.m
 edit: test/Index/Core/index-with-module.m
 
 Commit d9937b66f53a7e4fe768131a49bcc607cf3bc172 by blangmuir:
 Attempt to workaround Windows bots after my previous commit
 
 edit: test/Index/index-module.m
 
 Commit d43d77c857995e94c5b782eaebd225f54f93a536 by blangmuir:
 Remove the new module cache from the index-module test
 
 edit: test/Index/index-module.m
>>> 
>>> ___
>>> 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 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] Bugs not reproducible on master

[Daniel Dunbar via swift-dev]

> On Jul 13, 2016, at 6:16 AM, Alex Hoppen via swift-dev  
> wrote:
> 
> I’m currently crawling bugs.swift.org for bugs to fix and regularly encounter 
> bugs which I cannot reproduce on master anymore. What’s the standard protocol 
> for them? Close them with resolution "Can’t Reproduce" or "Done" or just add 
> a comment and let the reporter close it?

I suggest reporting that the bug doesn't reproduce with . setting the state to "Can't Reproduce" and resolved, and send back to 
the reporter to close it (or re-open if they think something is missed).

 - Daniel

> 
> – Alex
> ___
> 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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #5898

[Daniel Dunbar via swift-dev]

+Anders, I don't think we want the perf tests enabled in this config.

 - Daniel

> On Jun 22, 2016, at 7:52 PM, Jordan Rose via swift-dev  
> wrote:
> 
> This isn’t me. SwiftPM folks, is this real?
> 
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swiftpm/Tests/Basic/PathPerfTests.swift:23:
>  error: PathPerfTests.testJoinPerf_X10 : failed: The relative standard 
> deviation of the measurements is 12.993% which is higher than the max allowed 
> of 10.000%.
> Test Case 'PathPerfTests.testJoinPerf_X10' failed (7.808 seconds).
> 
> Jordan
> 
>> On Jun 22, 2016, at 19:51, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5898]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5898/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-15_10
>> Date of build:   Wed, 22 Jun 2016 19:36:24 -0700
>> Build duration:  14 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
>> Failed: 0 test(s), Passed: 8017 test(s), Total: 8017 test(s)
>> 
>> Changes
>> 
>> Commit 4562567bb35127e5a75b886809648318ea59b40f by jordan_rose:
>> [docs] LibraryEvolution: size_in_bits -> maximumFootprint.
>> 
>> edit: docs/LibraryEvolution.rst
>> 
>> Commit 2ce6f1eace6fa1cc095fd6e96181359c447aadeb by jordan_rose:
>> [docs] LibraryEvolution: Camel-case hypothetical attributes.
>> 
>> edit: docs/LibraryEvolution.rst
> 
> ___
> 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-build-dev] [RFC] Toolchain based build process

[Daniel Dunbar via swift-dev]

Hi Karl,

On Fri, Jun 10, 2016 at 2:38 AM, Karl via swift-build-dev <
swift-build-...@swift.org> wrote:

> We can’t separate building for ‘Build’ and building for an arbitrary
> ‘Host’. For those who don’t know, this is how cross-compiling works with
> Swift (this isn’t off-topic, I’m going to bring it back firmly to this
> proposal):
>
> Currently, when you install the compiler, the standard library is in
> (prefix)/lib/swift/(Target)/(arch). On OSX, we cross-compile the standard
> library for the iOS targets, so you’ll see subfolders for ‘macosx’,
> ‘iphoneos’, etc in there. All you need to cross-compile in Swift is the
> standard library; swiftmodules don’t need ‘ar’, so libraries don’t even
> need any binutils to cross-compile, which is refreshing. A cross-linker
> *is* unfortunately still required for executables (come on, LLD!).
>
> Grab the standard library from a linux machine and try:
> echo 'print("hello, world")' | ./swiftc —target=x86-unknown-linux-gnu
> -resource-dir {PATH_TO_LINUX_STDLIB} -emit-module -
>
> So when we’re cross-compiling the swift portions of the standard-library,
> we’re using the swift compiler we just made for Build, telling it to use
> Host’s lib/swift directory, and there it will find the correct subdirectory
> for Target. My native compiler for my OSX Build machine knows not to look
> for the Linux host’s own Target in swift-macosx-x86_64/lib/swift, but in
> swift-linux-armv7/lib/swift.
>
> —
>
> Okay, so that’s out of the way.
>
> There is an actual problem with how we build/configure the target
> libraries (Foundation, XCTest and libdispatch). We currently configure them
> like every other product (for each host), instead of for each target. A
> consequence of this is, for example, that we won’t try to build Foundation
> for cross-compile targets such as Android. What we should do is this:
>
> For each host:
> -> Build cmark/llvm/swift
> -> For each target of this host:
> -> -> Build Foundation/XCTest/libdispatch
> -> Build swiftpm
>
> When you look at it like this, from a tools // target-libraries
> perspective (swiftpm is an exception; it’s a host tool, but it depends on
> Foundation), I came up with a different idea (possibly, I’m not sure), that
> might also help the dependency issue, although I don’t know the specifics
> of it: I would suggest that after building swift, we install it, then build
> the target libraries and install them as we do so.
>
> That would give us a stable standard-library (lib/swift) location which we
> could treat like an installed system. So when Foundation builds (for each
> Target now), it sets -resource-dir to the installed Host copy of swift, and
> the Build swift compiler can find Target’s standard library (yeah, I know).
> It installs itself in there. Then XCTest comes along, it sets the same
> -resource-dir, so now it can find Foundation just with ‘import Foundation’
> and nothing else. In other words: every product after the swift compiler
> can assume its dependencies are like they’ve been installed on the system.
>
> I’m not sure if that’s what you’re referring to with a ‘toolchain-based’
> build process or not. The reason I think it might be is because I don’t
> think this would require big changes. We’d just have to install products
> after swift, then install the target libraries as we go. Foundation could
> even keep on generating build.ninja in-tree, sadly.
>

Yup, this is exactly what I was referring to (although for different
reasons).

 - Daniel


> There isn’t much difference between supporting one cross-host or
> supporting n cross-hosts. I would prefer ’n’, if we could get a nice
> argument syntax for it, because it’s more convenient to integrate with
> other tools, but it’s not a big deal. Actually, I have an idea for a better
> build-script argument syntax which would scale to NxM cross-compiled hosts
> and targets elegantly, but that’s a topic for another day.
>
> Karl
>
>
> On 3 Jun 2016, at 22:31, Daniel Dunbar via swift-dev <swift-dev@swift.org>
> wrote:
>
>
> On Jun 3, 2016, at 1:14 PM, Saleem Abdulrasool <compn...@compnerd.org>
> wrote:
>
> On Wed, Jun 1, 2016 at 2:18 PM, Daniel Dunbar via swift-dev <
> swift-dev@swift.org> wrote:
>
>> Hi all,
>>
>> The current build process for the overall Swift project (i.e., the
>> compiler + associated projects like Foundation, XCTest, and SwiftPM) relies
>> on each project having dependencies on the built artifacts of previously
>> built projects. Those dependencies are currently communicated to each
>> project in the chain through an ad hoc set of arguments to the individual
>> project's build process. This has been painful to maint

Re: [swift-dev] [RFC] Toolchain based build process

[Daniel Dunbar via swift-dev]

> On Jun 3, 2016, at 1:14 PM, Saleem Abdulrasool <compn...@compnerd.org> wrote:
> 
> On Wed, Jun 1, 2016 at 2:18 PM, Daniel Dunbar via swift-dev 
> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> Hi all,
> 
> The current build process for the overall Swift project (i.e., the compiler + 
> associated projects like Foundation, XCTest, and SwiftPM) relies on each 
> project having dependencies on the built artifacts of previously built 
> projects. Those dependencies are currently communicated to each project in 
> the chain through an ad hoc set of arguments to the individual project's 
> build process. This has been painful to maintain, and makes it hard to reason 
> about the environment that each of the associated projects are building 
> within.
> 
> Instead, I would like to move towards what I have been calling a 
> "toolchain-based" build process.
> 
> In this model:
> 
> 1. The entire build process will be organized as a sequential, incremental 
> construction of a complete toolchain.
> - Each individual project will build and copy its products into a 
> staging area.
> 2. The build script will always create a composed toolchain.
> - It will start with an empty toolchain, and merge in the content 
> from each project as it builds.
> - This will use rsync & hard-links to avoid needing to stay fast.
> 3. Each individual project build will just use the composed toolchain to 
> build.
> - This will replace the grab bag of options we use to communicate 
> between the projects.
> 4. At the end of the build, we will have constructed a complete toolchain 
> which can be installed (or used with Xcode).
> 
> Aside from simplifying the overall build process, this has a couple very nice 
> upsides:
> 
> 1. At the end of the build, the user has a complete toolchain. They can 
> install it, or use it as they would a distributed snapshot. This is very 
> beneficial for people who are only building the Swift project to get a more 
> recent version of the compiler.
> 
> 2. Each individual project can be built using the "official" build process 
> with a downloaded snapshot (assuming it is of a new enough version). This is 
> very beneficial for easing contribution to projects like Foundation, XCTest, 
> and SwiftPM which are pure Swift and have fast build times, but which 
> currently build in Swift CI using a very different process from the 
> snapshot-based workflow.
> 
> Concrete details:
> 
> 1. I do not plan to change the actual install process in the short term. The 
> actual install process used today relies on the CMake-based install process 
> for some projects (most importantly Swift) and isn't suitable for use in this 
> fashion (where incremental development speed is of high importance). Instead, 
> my plan is to teach the build script itself how to assemble the staging area 
> for each individual project, with the long term goal of using that for the 
> official install process instead of the CMake-based process.
> 
> 2. My plan is that the build script would only support building one "primary 
> product" (i.e. toolchain). That product may itself be a complete cross 
> compiler toolchain with support for multiple platforms, but the expectation 
> is that users would invoke the build script multiple times if building 
> multiple toolchains. However, to support Canadian Cross [1] build scenarios 
> the build script may need to manage the construction of two products, the 
> primary toolchain and the intermediate (cross compiling) toolchain used to 
> build the artifacts in the primary toolchain.
> 
> 3. As a concrete example of a problem this solves, SwiftPM currently doesn't 
> test its `swift-test` product in Swift CI, because that product requires 
> using all of the toolchain stack (swift, Foundation, and XCTest), but the 
> product itself is only intended to be used as part of a concrete toolchain. 
> As such, it doesn't know how to operate correctly when given the piecemeal 
> build products for each of those projects, and teaching it to do so would be 
> very cumbersome for us to maintain.
> 
> Feedback welcome!
> 
> Overall, I think that this would be a great change.
> 
> I am however slightly confused on why the build script needs to be concerned 
> about candian cross at all if it can be taught how to use a specified 
> toolchain.
> 
> Because these (standard at least as per auto tools) terms can be confusing:
> 
> [1] build - the platform where things are being built
> [2] host - the platform where the generated binaries will be run
> [3] target - the platform where the binaries generated by the compiler on the 
> host platform

Re: [swift-dev] Delaying the enforcement of ".self" out of Swift 3?

[Daniel Dunbar via swift-dev]

As just a user of the language, as much as I hate churn I personally wouldn't 
mind seeing this fixed. In this case, I think the laxness can make it harder 
for developers to form the right mental model of the language; I know I have 
personally stumbled over this in the past.

 - Daniel

> On Jun 2, 2016, at 2:00 PM, Jordan Rose via swift-dev  
> wrote:
> 
> We have a bug for this, https://bugs.swift.org/browse/SR-899. I had pretty 
> much the same reaction you did, which is that it's definitely a bug but it's 
> probably not worth changing right now.
> 
> Jordan
> 
> 
>> On Jun 2, 2016, at 13:21, Douglas Gregor via swift-dev  
>> wrote:
>> 
>> Hi all,
>> 
>> While working on some unrelated refactoring, I stumbled across a minor fix 
>> that would make use properly enforce “.self” when we want to get the 
>> metatype of a named type. For example, the Swift compiler currently 
>> (incorrectly) allows
>> 
>>  sizeof(UInt)
>> 
>> which should be
>> 
>>  sizeof(UInt.self)
>> 
>> The fix for this is actually pretty simple (patch attached), but the 
>> question is… do we want to fix the problem, if we think that we’ll get 
>> SE-0090 that makes “.self” go away?
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md
>> 
>> On the one hand, I want to fix the problem:
>> 
>>  * This came out of a desire to make the AST more sane. Essentially, the 
>> folding of expressions into TypeExprs—which will go away entirely if/when 
>> SE-0090 is implemented—is pulling in the parentheses describing call 
>> arguments. Without the fix, we still have weird AST.
>>  * SE-0090 is labeled as “deferred out of Swift 3”, so having the 
>> compiler not implement the stated language for an entire release cycle seems 
>> really unfortunate.
>> 
>> OTOH, I don’t want to jerk people’s code around, forcing them to add “.self” 
>> now only to remove it a year from now (or whenever).
>> 
>> Thoughts?
>> 
>>  - Doug
>> 
>> ___
>> 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 mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [swift-build-dev] Building custom toolchain

[Daniel Dunbar via swift-dev]

> On Jun 2, 2016, at 10:59 AM, bhargav gurlanka  wrote:
> 
> > I always run this after every build
> 
> If I understand you correctly, you first build swift and then run this script 
> to create the toolchain right?  
> 
> Are you using the `build-toolchain` script to build swift? I've tried doing 
> it sometime back and it included the testing also, which took a long time to 
> complete. Is there a way to quicken the build (by disabling tests, 
> incremental build, etc.,)?

No, part of the reason I developed that script is because I wanted to make a 
toolchain out of the build-script invocation I use for incremental development, 
which is this:
  ~/public/swift-project/swift/utils/build-script -R --llbuild --swiftpm

That works fine for iterative development, my "null" builds are about 5s. I run 
that with "--tests" if I want to also run all the tests (but often for my local 
iterative SwiftPM development I am just running the SwiftPM tests).

 - Daniel

> 
> 
> Regards,
> Bhargav Gurlanka
> 
> On 2 June 2016 at 23:06, Daniel Dunbar  > wrote:
> FWIW, this:
>   https://gist.github.com/ddunbar/598bf66952fba0e9d8aecc54995f018e 
> 
> is the script I currently use on OS X to get a working 
> "swift-dev.xctoolchain" out of a built Swift. It isn't designed to work for 
> anyone but me, but it should be easy to adapt.
> 
> I always run this after every build, and then use `TOOLCHAINS=swift-dev swift 
> build` (etc) to use the development compiler.
> 
> My "toolchain-based build process" proposal will hopefully make this a no-op.
> 
>  - Daniel
> 
>> On Jun 2, 2016, at 3:12 AM, bhargav gurlanka via swift-build-dev 
>> > wrote:
>> 
>> Hi all,
>> 
>> I'm trying to build a custom toolchain, but it is failing with error: 
>> 
>> --- Installing swift ---
>> + env DESTDIR=// /usr/local/bin/cmake --build 
>> /Users/bhargavg/Documents/workspaces/xcode/github/apple/build/bhargavg/swift-macosx-x86_64
>>  -- install
>> ninja: error: unknown target 'install'
>> swift/utils/build-script: fatal error: command terminated with a non-zero 
>> exit status 1, aborting
>> 
>> 
>> Script to build toolchain: 
>> 
>> #!/bin/bash
>> #
>> # Faster toolchain build: skips as much as possible.
>> #
>> # To use this toolchain from the command line:"
>> # export TOOLCHAINS=$(whoami)
>> #
>> # we build to the same prefix every time (instead of building
>> # to a versioned prefix) because every time the prefix changes
>> # *everything* rebuilds.
>> 
>> set -e
>> trap "exit;" SIGINT SIGTERM
>> 
>> SRCROOT="$HOME/Documents/workspaces/xcode/github/apple/"
>> 
>> ALIAS=$(whoami)
>> TOOLCHAIN_NAME="swift-${ALIAS}.xctoolchain"
>> TOOLCHAIN_PREFIX="$HOME/Library/Developer/Toolchains/${TOOLCHAIN_NAME}"
>> 
>> export TOOLCHAINS=default
>> 
>> if [[ $1 == "--reconfigure" ]]; then
>> RECONFIGURE="--reconfigure"
>> fi
>> 
>> # so if anything is put in the wrong place we will *see* it
>> cd "$HOME/Desktop"
>> 
>> "$SRCROOT/swift/utils/build-script" \
>> --release \
>> --llvm \
>> --llbuild \
>> --swiftpm \
>> --build-subdir="${ALIAS}" \
>> --assertions \
>> --no-swift-stdlib-assertions \
>> --install-prefix="${TOOLCHAIN_PREFIX}/usr" \
>> --lldb \
>> --darwin-xcrun-toolchain=mxcl \
>> -- \
>> --lldb-use-system-debugserver \
>> ${RECONFIGURE} \
>> --skip-ios \
>> --skip-tvos \
>> --skip-watchos \
>> --skip-build-linux \
>> --skip-build-freebsd \
>> --skip-build-cygwin \
>> --skip-build-ios \
>> --skip-build-ios-device \
>> --skip-build-ios-simulator \
>> --skip-build-tvos \
>> --skip-build-tvos-device \
>> --skip-build-tvos-simulator \
>> --skip-build-watchos \
>> --skip-build-watchos-device \
>> --skip-build-watchos-simulator \
>> --skip-build-xctest \
>> --skip-build-foundation \
>> --skip-build-libdispatch \
>> --skip-build-benchmarks \
>> --skip-test-cmark \
>> --skip-test-lldb \
>> --skip-test-swift \
>> --skip-test-llbuild \
>> --skip-test-swiftpm \
>> --skip-test-xctest \
>> --skip-test-foundation \
>> --skip-test-libdispatch \
>> --skip-test-linux \
>> --skip-test-freebsd \
>> --skip-test-cygwin \
>> --skip-test-osx \
>> --skip-test-ios-simulator \
>> --skip-test-ios-host \
>> --skip-test-tvos-simulator \
>> --skip-test-tvos-host \
>> --skip-test-watchos-simulator \
>> --skip-test-watchos-host \
>> --skip-test-benchmarks \
>> --skip-test-optimized \
>> --stdlib-deployment-targets=macosx-x86_64 \
>> 

Re: [swift-dev] [swift-build-dev] Building custom toolchain

[Daniel Dunbar via swift-dev]

FWIW, this:
  https://gist.github.com/ddunbar/598bf66952fba0e9d8aecc54995f018e
is the script I currently use on OS X to get a working "swift-dev.xctoolchain" 
out of a built Swift. It isn't designed to work for anyone but me, but it 
should be easy to adapt.

I always run this after every build, and then use `TOOLCHAINS=swift-dev swift 
build` (etc) to use the development compiler.

My "toolchain-based build process" proposal will hopefully make this a no-op.

 - Daniel

> On Jun 2, 2016, at 3:12 AM, bhargav gurlanka via swift-build-dev 
>  wrote:
> 
> Hi all,
> 
> I'm trying to build a custom toolchain, but it is failing with error: 
> 
> --- Installing swift ---
> + env DESTDIR=// /usr/local/bin/cmake --build 
> /Users/bhargavg/Documents/workspaces/xcode/github/apple/build/bhargavg/swift-macosx-x86_64
>  -- install
> ninja: error: unknown target 'install'
> swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 1, aborting
> 
> 
> Script to build toolchain: 
> 
> #!/bin/bash
> #
> # Faster toolchain build: skips as much as possible.
> #
> # To use this toolchain from the command line:"
> # export TOOLCHAINS=$(whoami)
> #
> # we build to the same prefix every time (instead of building
> # to a versioned prefix) because every time the prefix changes
> # *everything* rebuilds.
> 
> set -e
> trap "exit;" SIGINT SIGTERM
> 
> SRCROOT="$HOME/Documents/workspaces/xcode/github/apple/"
> 
> ALIAS=$(whoami)
> TOOLCHAIN_NAME="swift-${ALIAS}.xctoolchain"
> TOOLCHAIN_PREFIX="$HOME/Library/Developer/Toolchains/${TOOLCHAIN_NAME}"
> 
> export TOOLCHAINS=default
> 
> if [[ $1 == "--reconfigure" ]]; then
> RECONFIGURE="--reconfigure"
> fi
> 
> # so if anything is put in the wrong place we will *see* it
> cd "$HOME/Desktop"
> 
> "$SRCROOT/swift/utils/build-script" \
> --release \
> --llvm \
> --llbuild \
> --swiftpm \
> --build-subdir="${ALIAS}" \
> --assertions \
> --no-swift-stdlib-assertions \
> --install-prefix="${TOOLCHAIN_PREFIX}/usr" \
> --lldb \
> --darwin-xcrun-toolchain=mxcl \
> -- \
> --lldb-use-system-debugserver \
> ${RECONFIGURE} \
> --skip-ios \
> --skip-tvos \
> --skip-watchos \
> --skip-build-linux \
> --skip-build-freebsd \
> --skip-build-cygwin \
> --skip-build-ios \
> --skip-build-ios-device \
> --skip-build-ios-simulator \
> --skip-build-tvos \
> --skip-build-tvos-device \
> --skip-build-tvos-simulator \
> --skip-build-watchos \
> --skip-build-watchos-device \
> --skip-build-watchos-simulator \
> --skip-build-xctest \
> --skip-build-foundation \
> --skip-build-libdispatch \
> --skip-build-benchmarks \
> --skip-test-cmark \
> --skip-test-lldb \
> --skip-test-swift \
> --skip-test-llbuild \
> --skip-test-swiftpm \
> --skip-test-xctest \
> --skip-test-foundation \
> --skip-test-libdispatch \
> --skip-test-linux \
> --skip-test-freebsd \
> --skip-test-cygwin \
> --skip-test-osx \
> --skip-test-ios-simulator \
> --skip-test-ios-host \
> --skip-test-tvos-simulator \
> --skip-test-tvos-host \
> --skip-test-watchos-simulator \
> --skip-test-watchos-host \
> --skip-test-benchmarks \
> --skip-test-optimized \
> --stdlib-deployment-targets=macosx-x86_64 \
> --swift-enable-ast-verifier=0 \
> --build-swift-examples=0 \
> --build-swift-stdlib-unittest-extra=0 \
> --build-swift-static-stdlib=1 \
> --compiler-vendor=apple \
> 
> --swift-install-components="compiler;clang-builtin-headers;stdlib;sdk-overlay;license;sourcekit-xpc-service"
>  \
> --llvm-install-components="libclang;libclang-headers" \
> --install-swift=1 \
> --install-llbuild=1 \
> --install-swiftpm=1 \
> --install-destdir="/" \
> --install-lldb=1 \
> --toolchain-prefix="${TOOLCHAIN_PREFIX}"
> 
> 
> # doing by hand as the only other way to trigger this
> # is by specifying --installable-package, which tars
> # all installed products and is super slow
> 
> DATE=$(date +%Y.%m.%d)
> SWIFT_VERSION=$("${TOOLCHAIN_PREFIX}/usr/bin/swift" --version | ruby -e 
> 'ARGF.read =~ /Swift version (\d+\.\d(\.\d+)?(-.*?)?) /; print "#{$1}\n"')
> 
> if [[ "$SWIFT_VERSION" == "3.0-dev" ]]; then
> SWIFT_VERSION="3.0.0-dev"
> fi
> 
> VERSION="${SWIFT_VERSION}-${ALIAS}+${DATE}"
> 
> cat > "${TOOLCHAIN_PREFIX}/Info.plist" < 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
> ">
> 
> 
>   Aliases
>   
>   ${ALIAS}
>   
>   CompatibilityVersion
>   2
>   CFBundleIdentifier
>   

[swift-dev] [RFC] Toolchain based build process

[Daniel Dunbar via swift-dev]

Hi all,

The current build process for the overall Swift project (i.e., the compiler + 
associated projects like Foundation, XCTest, and SwiftPM) relies on each 
project having dependencies on the built artifacts of previously built 
projects. Those dependencies are currently communicated to each project in the 
chain through an ad hoc set of arguments to the individual project's build 
process. This has been painful to maintain, and makes it hard to reason about 
the environment that each of the associated projects are building within.

Instead, I would like to move towards what I have been calling a 
"toolchain-based" build process.

In this model:

1. The entire build process will be organized as a sequential, incremental 
construction of a complete toolchain.
- Each individual project will build and copy its products into a 
staging area.
2. The build script will always create a composed toolchain.
- It will start with an empty toolchain, and merge in the content from 
each project as it builds.
- This will use rsync & hard-links to avoid needing to stay fast.
3. Each individual project build will just use the composed toolchain to build.
- This will replace the grab bag of options we use to communicate 
between the projects.
4. At the end of the build, we will have constructed a complete toolchain which 
can be installed (or used with Xcode).

Aside from simplifying the overall build process, this has a couple very nice 
upsides:

1. At the end of the build, the user has a complete toolchain. They can install 
it, or use it as they would a distributed snapshot. This is very beneficial for 
people who are only building the Swift project to get a more recent version of 
the compiler.

2. Each individual project can be built using the "official" build process with 
a downloaded snapshot (assuming it is of a new enough version). This is very 
beneficial for easing contribution to projects like Foundation, XCTest, and 
SwiftPM which are pure Swift and have fast build times, but which currently 
build in Swift CI using a very different process from the snapshot-based 
workflow.

Concrete details:

1. I do not plan to change the actual install process in the short term. The 
actual install process used today relies on the CMake-based install process for 
some projects (most importantly Swift) and isn't suitable for use in this 
fashion (where incremental development speed is of high importance). Instead, 
my plan is to teach the build script itself how to assemble the staging area 
for each individual project, with the long term goal of using that for the 
official install process instead of the CMake-based process.

2. My plan is that the build script would only support building one "primary 
product" (i.e. toolchain). That product may itself be a complete cross compiler 
toolchain with support for multiple platforms, but the expectation is that 
users would invoke the build script multiple times if building multiple 
toolchains. However, to support Canadian Cross [1] build scenarios the build 
script may need to manage the construction of two products, the primary 
toolchain and the intermediate (cross compiling) toolchain used to build the 
artifacts in the primary toolchain.

3. As a concrete example of a problem this solves, SwiftPM currently doesn't 
test its `swift-test` product in Swift CI, because that product requires using 
all of the toolchain stack (swift, Foundation, and XCTest), but the product 
itself is only intended to be used as part of a concrete toolchain. As such, it 
doesn't know how to operate correctly when given the piecemeal build products 
for each of those projects, and teaching it to do so would be very cumbersome 
for us to maintain.

Feedback welcome!

 - Daniel

[1] https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross

___
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 15.10 (master) #5339

[Daniel Dunbar via swift-dev]

Mine, fixed in 130d352.

 - Daniel

> On May 27, 2016, at 3:39 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5339]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5339/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Fri, 27 May 2016 15:26:23 -0700
> Build duration:   12 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
> Failed: 0 test(s), Passed: 7962 test(s), Total: 7962 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 291 test(s), Total: 291 test(s)
> 
> Changes
> 
> Commit c9d44eefe86b6cd9a77cfd2cc613dc6b4d8dc0ab by daniel_dunbar:
> [Tests] Add a smoke test for `swift test`.
> 
> edit: Tests/Functional/ValidLayoutTests.swift
> add: Fixtures/ValidLayouts/PackageWithTests/Tests/LinuxMain.swift
> edit: Tests/Functional/Utilities.swift
> add: Fixtures/ValidLayouts/PackageWithTests/Package.swift
> add: Fixtures/ValidLayouts/PackageWithTests/Tests/Foo/FooTests.swift
> add: Fixtures/ValidLayouts/PackageWithTests/Sources/Foo.swift
> 
> Commit d7c0d5f5b19cc2b8b9e16932a483726e7634ee6c by daniel_dunbar:
> Revert "[Tests] Remove an unnecessary sleep()."
> 
> edit: Tests/Functional/MiscellaneousTests.swift

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

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (master) #1407

[Daniel Dunbar via swift-dev]

This failure makes it look like the binaries we build no longer are capable of 
finding their runtime libraries:
--
Command 7: 
"/tmp/swift-integration-tests/test-xctest-package/Output/test-xctest-package.py.tmp.dir/tool/.build/debug/tool"
Command 7 Result: 127
Command 7 Output:
None

Command 7 Stderr:
/tmp/swift-integration-tests/test-xctest-package/Output/test-xctest-package.py.tmp.dir/tool/.build/debug/tool:
 error while loading shared libraries: libFoundation.so: cannot open shared 
object file: No such file or directory
--

That sounds a lot like:
  https://bugs.swift.org/browse/SR-1625
and I wonder if this is fallout of the linker-related changes that have gone in?

Filed:
  https://bugs.swift.org/browse/SR-1631
to track this.

 - Daniel

> On May 27, 2016, at 9:07 AM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1407]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1407/ 
> 
> Project:  oss-swift-package-linux-ubuntu-15_10
> Date of build:Fri, 27 May 2016 08:36:15 -0700
> Build duration:   31 min
> Identified problems:
> 
> 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 ccaa3d1c9c8a581ce0cd696a3b0d6ab713908e40 by nicolas.despres:
> Parser accepts no explicit outputs.
> 
> edit: src/manifest_parser.cc
> edit: src/manifest_parser_test.cc
> edit: src/graph_test.cc
> 
> Commit 615cfd4a1081bda4f99f011eebb299e0565ea609 by jgroff:
> Clang importer: Fix the 'self' type of imported ObjC generic members.
> 
> edit: test/SILGen/objc_imported_generic.swift
> edit: lib/ClangImporter/ImportDecl.cpp
> 
> Commit 803a6b095bc9f420a825d06ccd85175f3a7331dc by spestov:
> Reflection: Emit metadata for fixed-layout SIL boxes
> 
> edit: lib/IRGen/IRGenSIL.cpp
> edit: lib/IRGen/GenHeap.cpp
> edit: test/Reflection/capture_descriptors.sil
> edit: lib/IRGen/GenHeap.h
> edit: lib/IRGen/IRGenModule.h
> add: validation-test/Reflection/functions_objc.swift
> add: test/Reflection/box_descriptors.sil
> edit: validation-test/Reflection/functions.swift
> edit: lib/IRGen/GenReflection.cpp
> 
> Commit a86e39dd4cec09abb5d4c08e57652db242d6bc8b by spestov:
> Reflection: Don't emit associated type records for conformances without
> 
> edit: lib/IRGen/GenReflection.cpp
> edit: test/Reflection/typeref_decoding.swift
> edit: test/Reflection/typeref_decoding_objc.swift
> 
> Commit 72e308679c0a3d0a8d43483428d0c2adef6d2146 by spestov:
> Reflection: Record builtin and imported types referenced from captures
> 
> edit: validation-test/Reflection/functions_objc.swift
> edit: test/Reflection/Inputs/ObjectiveCTypes.swift
> edit: test/Reflection/typeref_decoding_objc.swift
> edit: lib/IRGen/GenReflection.cpp
> 
> Commit e2cf23d971b267183d871cc0a4208382bde493e4 by spestov:
> Reflection: Don't emit builtin descriptors for imported classes
> 
> edit: include/swift/Reflection/Records.h
> edit: test/Reflection/Inputs/ObjectiveCTypes.swift
> edit: validation-test/Reflection/functions.swift
> edit: lib/IRGen/IRGenModule.h
> edit: test/Reflection/typeref_decoding_objc.swift
> edit: stdlib/public/Reflection/TypeLowering.cpp
> edit: lib/IRGen/GenReflection.cpp
> edit: test/Reflection/typeref_decoding_imported.swift
> 
> Commit 97fd1a741105cfae7625068ea35795ff66a66dce by spestov:
> Reflection: Emit field metadata for @objc classes
> 
> edit: lib/IRGen/GenReflection.cpp
> edit: test/Reflection/typeref_decoding_objc.swift
> 
> Commit 7a46b0f23f9d615e7ecff434de679320f6871230 by spestov:
> Reflection: Emit descriptors for referenced imported protocols
> 
> edit: test/Reflection/Inputs/ObjectiveCTypes.swift
> edit: lib/IRGen/IRGenModule.h
> edit: validation-test/Reflection/functions_objc.swift
> edit: test/Reflection/typeref_decoding_objc.swift
> edit: lib/IRGen/GenReflection.cpp
> 
> Commit 60dff0109356a4e0bb88f38cbbbad6909df9e575 by spestov:
> Reflection: Simplify associated type metadata emission
> 
> edit: lib/IRGen/IRGenModule.h
> edit: test/Reflection/typeref_decoding.swift
> edit: lib/IRGen/GenStruct.cpp
> edit: lib/IRGen/GenDecl.cpp
> edit: lib/IRGen/GenMeta.cpp
> edit: lib/IRGen/GenEnum.cpp
> edit: lib/IRGen/GenClass.cpp
> edit: lib/IRGen/GenReflection.cpp
> 
> Commit 2b1bfcb838f9ddc8625975bb5df64c5e0dff5eab by spestov:
> Reflection: Fix tests for iPhoneOS
> 
> edit: validation-test/Reflection/functions_objc.swift
> edit: test/Reflection/Inputs/ObjectiveCTypes.swift
> edit: test/Reflection/typeref_decoding_objc.swift
> 
> Commit 4c8754634822d7b9d0693be508fef0e89eec706e by spestov:
> Reflection: More robust typeref_decoding_objc test
> 
> edit: test/Reflection/typeref_decoding_objc.swift
> edit: test/Reflection/Inputs/ObjectiveCTypes.swift

Re: [swift-dev] build-script -x freezing?

[Daniel Dunbar via swift-dev]

Can someone who can reproduce this issue please file a bug on bugs.swift.org 
with as much information as possible about what exactly is hanging?

 - Daniel

> On May 26, 2016, at 10:53 AM, Geoffrey Wiseman via swift-dev 
>  wrote:
> 
> 
>> On May 26, 2016, at 1:20 AM, Jacob Bandes-Storch > > wrote:
>> Actually, I think this was a Python problem for me. I had installed Python 
>> via Homebrew — running "brew unlink python" before a build-script invocation 
>> made it work fine.
> 
> 
> As soon as I read this, I thought I should probably try — many of my dev 
> tools are brew-installed, so it was worth a shot.
> 
> It worked. Brew unlink, and suddenly the build script completes. Some 
> interaction between the build script and other versions/installations of 
> Python, I guess.
> 
>   - Geoffrey
> --
> Geoffrey Wiseman
> Codiform: Professional Software
> http://www.codiform.com 
> ___
> 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 14.04 (master) #4841

[Daniel Dunbar via swift-dev]

The failure cascade is in full effect:

lit.py: lit.cfg:881: note: Using platform module dir: 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/%target-sdk-name/x86_64
-- Testing: 8207 tests, 48 threads --
Testing: 0 
FAIL: Swift :: ClangModules/simd.swift (207 of 8207)
 <> TEST 'Swift :: ClangModules/simd.swift' FAILED 

Script:
--
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift
 -frontend -target x86_64-unknown-linux-gnu   -enable-source-import -sdk 
'/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test'/Inputs/clang-importer-sdk
 -I 
'/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test'/Inputs/clang-importer-sdk/swift-modules
   -module-name main -parse -verify 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test/ClangModules/simd.swift
--
Exit Code: 1

Command Output (stderr):
--
 
<>/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test/ClangModules/simd.swift:18:5:
 error: unexpected error produced: 'b17' used within its own type
let b17 = makes_byte17 // expected-error{{unresolved identifier 'makes_byte17'}}
^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test/ClangModules/simd.swift:18:5:
 error: unexpected error produced: could not infer type for 'b17'
let b17 = makes_byte17 // expected-error{{unresolved identifier 'makes_byte17'}}
^

--


Testing: 0 .. 10.. 20.. 30.. 40.. 50
FAIL: Swift :: compiler_crashers_fixed/02046-swift-pattern-operator.swift (4510 
of 8207)
 TEST 'Swift :: 
compiler_crashers_fixed/02046-swift-pattern-operator.swift' FAILED 

Script:
--
not 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift
 -frontend -target x86_64-unknown-linux-gnu  
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift
 -parse
--
Exit Code: 1

Command Output (stderr):
--
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:11:12:
 error: definition conflicts with previous value
class a {
   ^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:11:9:
 note: previous definition of 'T' is here
class a {
^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:17:1:
 error: expected ')' in expression list
protocol a {
^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:15:2:
 note: to match this opening '('
c(n: NSObject {
 ^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:17:1:
 error: declaration is only valid at file scope
protocol a {
^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:12:5:
 error: computed property must have an explicit type
var b {
^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:21:1:
 error: expected declaration

^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:11:7:
 note: in declaration of 'a'
class a {
  ^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:11:33:
 error: use of undeclared type 'B'
class a {
^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:11:7:
 error: invalid redeclaration of 'a'
class a {
  ^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/validation-test/compiler_crashers_fixed/02046-swift-pattern-operator.swift:9:7:
 note: 'a' previously declared here
class a {
  ^

[swift-dev] Argument unused warnings

[Daniel Dunbar via swift-dev]

Something broke yesterday causing Swift to report gobs of argument unused 
warnings, see:
  https://bugs.swift.org/browse/SR-1546
for a reference.

Does anyone know who this should go to?

 - Daniel

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

Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

[Daniel Dunbar via swift-dev]

> On May 9, 2016, at 7:35 PM, Brian Gesiak  wrote:
> 
> Thanks for the feedback, everyone!
> 
> Porting SourceKit to Linux seems like a reasonable solution to me. Still, 
> there are 354 lines of code in tools/SourceKit that reference "XPC", so a 
> Linux port will take more than a few lines of source code changes.
> 
> I imagine we'll need to insert some sort of shim layer that will use libxpc 
> on OS X, and a hand-rolled solution for Linux. Alternatively, if anyone knows 
> of a good open-source library that implements IPC for Linux (and that has a 
> permissible license), that would be a great help here.
> 
> I've also seen the idea proposed that Apple could open-source libxpc, which 
> we could then port to Linux. This would involve less work than installing a 
> shim layer in SourceKit, then in addition implementing a Linux IPC library 
> behind the shim. I don't know who I could talk about making this happen, but 
> in any case, I filed a Radar:
> 
> * rdar://26187442
> * https://openradar.appspot.com/26187442 
> 
> > 2. Somehwat unrelated, but the compiler itself (`swiftc`) is not yet 
> > written in a way that it can be used from SourceKit.
> 
> Could you explain this further?

Basically, I just meant that SourceKit doesn't currently have APIs for driving 
the compiler (driver), just interrogating the AST.

 - Daniel

> 
> - Brian Gesiak
> 
> 
> On Sat, May 7, 2016 at 4:18 AM, Drew Crawford  > wrote:
> 
>> On May 6, 2016, at 3:04 PM, Daniel Dunbar > > wrote:
>> 
>> The conclusion was that after weighing all of the tradeoffs, it made the most
>> sense to encourage porting of SourceKit to Linux and then using it to build 
>> out
>> the Linux test discovery feature. This was most in line with a desirable
>> long-term direction without being blocked on language design.
> 
> For whatever it's worth, this direction is a win on my side as well.
> 
> In addition to the problem of test discovery (for which I'm using an 
> out-of-tree parser), I have a lot of other problems entirely outside of 
> testing that rely on source-level queries similar to the XCTest problem.  
> This is things like parsing comments for documentation, implementing 
> dispatch-by-string, etc.  I currently rely on SK in many cases, but lack of 
> support on Linux is a major issue.  Lack of features exposed in the SK APIs 
> is another issue.
> 
> IMO it is a clear win to invest in resolving these problems inside SK.  Right 
> now it is basically a glorified Xcode daemon, but I think it can have a 
> bright future as a multi-client tool if we're willing to invest in making 
> that happen.
> 

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

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (master) #1250

[Daniel Dunbar via swift-dev]

I can't tell what failed here:


YEAR:2016
MONTH:05
DAY:09
TOOLCHAIN_VERSION:swift-DEVELOPMENT-SNAPSHOT-2016-05-09-a
ARCHIVE_DIR:swift-DEVELOPMENT-SNAPSHOT-2016-05-09-a-1229
./clang: 9f0d189
./llbuild: 0702f53
./swift_integration_tests: 98f6c6d
./llvm: dffa09f
./swift: de7ef4b
./swiftpm: b26305a
./swift_corelibs_xctest: f7b2ad4
./cmark: 5af77f3
./lldb: 5737bf8
./ninja: 63a8584
./compiler_rt: f2cfa77
./swift_corelibs_foundation: ad02ee6
find: 
`/home/codesign/tmp/swift-DEVELOPMENT-SNAPSHOT-2016-05-05-a-1192-WORKSPACE-ubuntu14.04':
 No such file or directory
find: 
`/home/codesign/tmp/swift-DEVELOPMENT-SNAPSHOT-2016-05-06-a-1193-WORKSPACE-ubuntu14.04':
 No such file or directory
find: 
`/home/codesign/tmp/swift-DEVELOPMENT-SNAPSHOT-2016-05-06-a-1193-WORKSPACE-ubuntu15.10':
 No such file or directory
-- scp toolchain tar --
WARNING: Your password has expired.
Password change required but no TTY available.
Build step 'Execute shell' marked build as failure
[BFA] Scanning build for known causes...
[BFA] No failure causes found
[BFA] Done. 0s
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Last: 1249 SUCCESS
Current: 1250 FAILURE
Sending email to: fs.out...@gmail.com jan.dvor...@yahoo.com milse...@apple.com 
daniel_dun...@apple.com dgre...@apple.com dan...@duan.org mishal_s...@apple.com
Finished: FAILURE

> On May 9, 2016, at 12:40 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1250]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1250/ 
> 
> Project:  oss-swift-package-linux-ubuntu-15_10
> Date of build:Mon, 09 May 2016 00:09:46 -0700
> Build duration:   30 min
> 
> Changes
> 
> Commit 6fd6675296389896065e11fef41f2cb4b654b520 by fs.output:
> [build-script] Don't run other products tests in "only_long" mode.
> 
> edit: utils/build-script
> 
> Commit a8cebdc5d3443252ab79f51a463b1475bbc0c2d5 by milseman:
> [swift_newtype] Special handling for Notifications
> 
> edit: lib/ClangImporter/ImportType.cpp
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: lib/ClangImporter/ClangImporter.cpp
> edit: lib/ClangImporter/ImporterImpl.h
> edit: test/IDE/Inputs/custom-modules/Newtype.h
> edit: test/IDE/newtype.swift
> edit: test/IRGen/newtype.swift
> edit: test/Inputs/clang-importer-sdk/usr/include/Foundation.h
> 
> Commit 8ca22f8729f5343e76cc344388f6e3e68579bc3c by milseman:
> [Clang importer] Minor cleanup
> 
> edit: lib/ClangImporter/ClangImporter.cpp
> 
> Commit b4a58650dd95262010d5ae2a91be311a4ab3d37d by dgregor:
> [SE-0033] Add _SwiftNewtypeWrapper protocol for swift_newtype'd types.
> 
> edit: test/IRGen/newtype.swift
> edit: lib/IRGen/GenMeta.cpp
> edit: stdlib/public/core/CMakeLists.txt
> edit: test/IDE/newtype.swift
> edit: include/swift/AST/KnownProtocols.def
> edit: stdlib/public/core/GroupInfo.json
> edit: lib/ClangImporter/ImportDecl.cpp
> add: stdlib/public/core/NewtypeWrapper.swift
> 
> Commit de7ef4b6760c551782ed5eb4f09854d1dd69dc59 by dgregor:
> [Clang importer] Don't prefix-strip notification names.
> 
> edit: test/IDE/Inputs/custom-modules/Newtype.h
> edit: lib/ClangImporter/ClangImporter.cpp
> edit: test/IDE/newtype.swift
> edit: test/IRGen/newtype.swift
> 
> Commit f31f6dc015980700126f4492bb4e2fe0caed0ea7 by jan.dvorsky:
> Pkgconfig flags need to inherit + add more, not overwrite
> 
> edit: Sources/Xcodeproj/Module+PBXProj.swift
> 
> Commit f648bbb1478b70c64e332b2232526998fad35433 by daniel:
> SR-1304 [Build] Handle escaped spaces parsing cFlags and libs (#326)
> 
> add: Tests/Build/pkgconfigInputs/escaped_spaces.pc
> edit: Tests/PkgConfig/PkgConfigParserTests.swift
> edit: Sources/PkgConfig/PkgConfig.swift
> 
> Commit 00a2fb0563fca1bb2cc6646049707014955c979f by daniel_dunbar:
> [tests] Move `escaped_spaces.pc` to correct location.
> 
> add: Tests/PkgConfig/pkgconfigInputs/escaped_spaces.pc
> delete: Tests/Build/pkgconfigInputs/escaped_spaces.pc
> 
> Commit eaa07b8ebb2e0c56b6b6ee0e53bea40a06c018b6 by daniel_dunbar:
> [tests] Protect a test against TOOLCHAINS being set.
> 
> edit: Tests/Xcodeproj/GenerateXcodeprojTests.swift
> 
> Commit b26305a5ac49351102088e6d4ef28bc00a87896f by daniel_dunbar:
> [swift-build] Add a hidden --ignore-dependencies option.
> 
> edit: Sources/swift-build/main.swift
> edit: Sources/swift-build/usage.swift

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

Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

[Daniel Dunbar via swift-dev]

Sorry for the delay in following up.

I have had several long discussions on this topic with Dmitri and others, which
I will try to summarize here:

*TL;DR*: We think the right long-term path forward is to pursue porting
SourceKit to Linux, and would like to explore that direction first before trying
to develop a compromise which either (a) uses internal and likely-to-break APIs
(e.g., dump-ast) or (b) devotes significant engineering resources to a "right
solution" for this problem, but which will only solve this problem and not other
issues where having an API for use with the Swift language.

## Problem Statement

The XCTest API has historically been defined in terms of methods with a
particular naming convention `test...` which were in subclasses of XCTestCase.

On OS X, these methods can be found via the Objective-C runtime but that does
not work on Linux. Our current solution on Linux requires manual specification
of all of the test methods, and is a huge maintenance burden for people trying
to use XCTest on Linux or maintain cross-platform projects.

## Background

This feature works on OS X in two ways:

1. As mentioned, tests are run by dynamic discovery through the Objective-C
   runtime when the bundle containing the tests is executed.
   
2. Within the Xcode IDE, tests are "discovered" (for use in UI) through the use
   of the Xcode indexer.
   
   The mechanism at work here, for Swift, is a combination of functionality in
   the indexing engine (to aggregate and query results) and the raw underlying
   data provided by SourceKit.
   
   We would like any implementation of this feature to share as much code as
   possible with SourceKit and Xcode's implementation in order for
   cross-platform projects to behave predictably.
   
It also happens that SwiftPM has several other needs for API-based interactions
with the functionality in the Swift compiler. Several examples:
   
* We would like to be able to enforce the strictness of the `Package.swift`
  manifest file format. This requires APIs to interact with the Swift
  AST. https://bugs.swift.org/browse/SR-1433
  
* We would like to support advanced features for dealing with automatic
  inter-module dependencies. For example, one idea which has been proposed is
  that if a module attempted to import a module upon which it did not have a
  dependency, that we would prompt the developer if this dependency should
  automatically be added to the manifest. Doing this feature well requires
  APIs to interact with the Swift compiler as it parses source code and
  reports diagnostics.
  
* We would like to understand the current level of parallelism being used by
  the Swift compiler, so that llbuild can accurately schedule work. This
  requires APIs for interacting with an in-flight compilation process.

## Discussion

We discussed several avenues of attack on this problem. I will go through them
one by one. I am just attempting to summarize the conversation, obviously there
is a ton of nuance to each point, and hopefully other people will chime in if I
missed something important.

### Language Features

One way to view this problem is that XCTest's API (i.e., depending on test
naming and dynamic discovery) is a poor fit for Swift today, and that this
problem should be tackled in that direction.

For example, the Swift compiler itself has a test framework that does not depend
on dynamic discovery. One could also imagine language-level features which would
solve the arbitrary problem of wanting to find discoverable things; that could
take the form of an `@XCTest` attribute, or "generalized attribute" support.

The current mission for Swift 3, however, is API parity between Linux and OS X,
and so this direction does not lead to any short term solution. For that reason,
while many of us ultimately think this is the right long term direction, we need
to find another one as well.

### Custom "Supported" XCTest Feature

The next option is to pursue a custom, but "supported" feature intended to
tackle this problem head on. Some proposals that have come up are, e.g., a new
compiler flag which emits the list of test methods.

This approach has a couple unfortunate properties:

1. It is non-trivial. We can either design this as an incredibly XCTest specific
   feature requiring understanding of the backend (compiler directly emits
   metadata into .o file), or a midway feature (compiler tells us list of test
   methods, but then we have to manage incremental compilation and the desire to
   not compile things multiple times more than necessary ourselves).
   
2. It is not-reusable. The work we do here doesn't help with any of the other
   ways we want to use the Swift compiler as an API.
   
### Implement an API-based Interface

This approach means porting SourceKit to Linux, and then building this feature
on top of that (that itself will be non-trivial, which is something not to be
glossed over).

Everyone generally agrees we should have some kind of API-based 

Re: [swift-dev] Why are we re-linking?

[Daniel Dunbar via swift-dev]

Is it so much work to move the data out of line (as Chris suggested) that we 
shouldn't just do that and involve another "mode"?

 - Daniel

> On May 6, 2016, at 9:23 AM, Dmitri Gribenko via swift-dev 
>  wrote:
> 
> On Fri, May 6, 2016 at 9:16 AM, Jordan Rose  wrote:
>> Hm. That might be a nice balance, and it’s not entirely a lie: that’s the
>> version of the compiler that you’re using, if not the stdlib and runtime.
>> I’d still like to put it behind a flag, so that we can turn it off it
>> certain configurations, like #2105 attempted to do.
>> 
>> Dmitri, any comments, since you caught the issue last time?
> 
> I think this would be a reasonable balance for local development.  For
> releases that CI produces I think this change will cause confusion
> because the git hashes that are tagged would not match the git hashes
> included in the compiler version.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> ___
> 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] Linux test failure

[Daniel Dunbar via swift-dev]

Awesome, thanks!

 - Daniel

> On May 5, 2016, at 4:17 PM, Mark Lacey <mark.la...@apple.com> wrote:
> 
> 
>> On May 5, 2016, at 12:36 PM, Daniel Dunbar via swift-dev 
>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>> 
>> Anyone know what is up with this Linux test failure? We keep seeing it block 
>> @swift-ci merges:
>> Failing Tests (1):
>> Swift :: 
>> compiler_crashers/28279-swift-archetypebuilder-potentialarchetype-getnestedtype.swift
> 
> I’m pretty sure I saw this fail locally once on OS X. I suspect it is just 
> randomly not crashing from time to time because it’s a use after free. It’s 
> an easy fix, so I just went ahead and fixed it. There is a PR waiting review 
> by Doug: https://github.com/apple/swift/pull/2415 
> <https://github.com/apple/swift/pull/2415>
> 
> Mark
> 

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

Re: [swift-dev] Building SwiftPM with Foundation

[Daniel Dunbar via swift-dev]

What you will need to do to make this work is to get the "fake toolchain" to 
look like how an actual toolchain looks on disk (e.g., libFoundation in the 
same relative position, in `/../lib/swift/linux`), presumably using 
a symlink. The special rpath is what is causing the built swift-build (in this 
case the stage1 swift-build) to look in that directory for its libraries. If 
libFoundation.so is there, then that should suffice for it to be found and 
loaded.

 - Daniel

> On May 5, 2016, at 2:04 AM, Bouke Haarsma via swift-dev  
> wrote:
> 
> For SwiftPM, I'm looking to replace some POSIX calls with Foundation. NSTask
> and NSFileManager amongst others. I've created a few PRs already for this, see
> [1]. However before these can be merged, the build scripts need to be adjusted
> to allow SwiftPM to build against Foundation.
> 
> There has already been some pointers posted in the comments on one of these 
> PRs,
> see [2]. I tried to implement those, see my changes to the swift build-script 
> in
> [3] and the "fake toolchain" in SwiftPM in [4]. However SwiftPM builds stage1;
> stage2 is still failing. I don't know how to proceed; I've only scratched the 
> surface regarding build systems and the many tools used to build the various 
> swift parts. I would really love some help going forward.
> 
> $ swift/utils/build-script -R --swiftpm
> (...)
> --- bootstrap: note: building self-hosted 'swift-build': env 
> SWIFT_EXEC=/media/sf_Developer/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug/swiftc
>  
> SWIFT_BUILD_PATH=/media/sf_Developer/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64
>  
> /media/sf_Developer/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug/swift-build-stage1
>  -Xlinker -rpath -Xlinker $ORIGIN/../lib/swift/linux -Xlinker -L -Xlinker 
> /media/sf_Developer/apple/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation
>  -Xlinker -rpath -Xlinker 
> /media/sf_Developer/apple/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation
>  -Xswiftc 
> -I/media/sf_Developer/apple/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation
>  -Xswiftc 
> -I/media/sf_Developer/apple/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation/usr/lib/swift
> 
> /media/sf_Developer/apple/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug/swift-build-stage1:
>  error while loading shared libraries: libFoundation.so: cannot open shared 
> object file: No such file or directory
> --- bootstrap: error: build failed with exit status 127
> 
> - Bouke
> 
> [1]: https://github.com/apple/swift-package-manager/pulls/Bouke 
> 
> [2]: 
> https://github.com/apple/swift-package-manager/pull/292#issuecomment-216508823
>  
> 
> [3]: https://github.com/apple/swift/compare/master...Bouke:swiftpm-foundation 
> 
> [4]: 
> https://github.com/apple/swift-package-manager/compare/ef491db...Bouke:swiftpm-foundation
>  
> ___
> 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-users] Swift Package Manager and main.swift

[Daniel Dunbar via swift-dev]

My preference here is that SwiftPM treat "Main.swift" as an error (and suggest 
"main.swift"), for now. If we agree the compiler should support it as a synonym 
for main.swift, then we can remove that.

 - Daniel

> On May 2, 2016, at 10:55 AM, Jordan Rose via swift-dev  
> wrote:
> 
> If it were just SwiftPM that would be fine, but I'd like someone to sign off 
> on it being okay to (potentially) break existing Xcode projects as well.
> 
> (This needs Xcode- and compiler-side changes as well, unfortunately. It's not 
> just the package manager.)
> 
> Jordan
> 
> 
>> On May 2, 2016, at 10:52, Max Howell > > wrote:
>> 
>> SwiftPM is case-insensitive about its conventions in general, so I consider 
>> this a bug.
>> 
>> It’s possible it’ll break existing projects, but well, existing projects are 
>> breaking constantly at this time due to language changes, so this is just 
>> another thing.
>> 
>>> On May 2, 2016, at 10:33 AM, Natthan Leong via swift-dev 
>>> > wrote:
>>> 
>>> Maybe that's why we should introduce the addition of 'Main.swift' before 
>>> the Swift Package Manager (and Swift 3.0) hits stable?
>>> 
>>> I've never requested to drop 'main.swift'. I merely prefer the additional 
>>> support for 'Main.swift'. Library/Frameworks should not have 'Main.swift' 
>>> imho as it leads to further confusion.
>>> 
>>> If the compiler and Xcode team find this too difficult to add support for 
>>> and not for any other reasons, I'd be okay with sticking with 'main.swift'. 
>>> Just find it odd for reasons specified throughout this email thread.
>>> 
>>> On May 2, 2016, at 10:20, Jordan Rose >> > wrote:
>>> 
 My concern is not about people who have both main.swift and Main.swift; 
 it's people who have libraries/frameworks (no main.swift) where one of the 
 source files happens to be named Main.swift. This isn't likely, but it is 
 possible.
 
 We're certainly not going to drop "main.swift" in favor of "Main.swift", 
 so the question would just be if we wanted to add "Main.swift". And I 
 don't think we want different rules for Xcode and the package manager, 
 especially not when the package manager can generate simple Xcode projects.
 
 Jordan
 
 
> On May 2, 2016, at 10:09, Natthan Leong  > wrote:
> 
> Hi,
> 
> Isn't it odd to have both main.swift and Main.swift for a project?
> 
> Considering Swift 3 provides source breaking changes, can this be still 
> worth an side effort to pursue with the compiler team as advised by 
> Kostiantyn in the bug report? If so, how'd I approach them regarding this?
> 
> Isn't the Swift Package Manager a (new) tool in handling Swift code? Is 
> this really the case where a minor change/addition to a convention is so 
> difficult that it shouldn't be done? Can't Xcode support only either 
> Main.swift or main.swift in the future?
> 
> The bug report is linked here
> https://bugs.swift.org/browse/SR-1379 
> 
> 
> On May 2, 2016, at 09:34, Jordan Rose  > wrote:
> 
>> [+swift-dev, bcc swift-users] I’d be fine with supporting “Main.swift”. 
>> The one downside is that it could change behavior for existing projects 
>> relying on “Main.swift” being a library file, and that might mean it’s 
>> not worth making a change.
>> 
>> Jordan
>> 
>> 
>>> On May 1, 2016, at 23:34, Kostiantyn Koval via swift-users 
>>> > wrote:
>>> 
>>> Hi there,
>>> 
>>> main is common used naming for executables that contains main function. 
>>> It’s required by Swift compiler and Swift Package Manager can’t do 
>>> anything about that.
>>> If you create a simple command line tool in Xcode, it will create 
>>> main.swift file. If you try to rename it, it will feil.
>>> I think this is correct behaviour.
>>> If you still think that Swift should support Main.swift with upper case 
>>> letter, than it should be discussed with compiler team.
>>> 
>>> - Kostiantyn
>>> 
>>> > Hi there,
>>> > 
>>> > This is what happened as I was trying out the Swift Package Manager 
>>> > for another project similar to the one shown below:
>>> > 
>>> > ~ $ mkdir example
>>> > ~ $ cd example/
>>> > example $ touch Package.swift
>>> > example $ mkdir Sources
>>> > 
>>> > example $ vi Sources/Example.swift
>>> > example $ cat Sources/Example.swift
>>> > func printOther() {
>>> > print("other")
>>> > }
>>> > 
>>> > example $ vi Sources/Main.swift
>>> > example 

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 - Long Test (master) #70

[Daniel Dunbar via swift-dev]

--
Test Suite 'All tests' started at 18:01:00.742
Test Suite 'TestFoundation.xctest' started at 18:01:00.745
Test Suite 'TestNSAffineTransform' started at 18:01:00.745
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10-long-test/swift/utils/build-script-impl:
 line 2029:  4531 Segmentation fault  (core dumped) 
LD_LIBRARY_PATH="${INSTALL_DESTDIR}"/"${INSTALL_PREFIX}"/lib/swift/:"${build_dir}/Foundation":"${XCTEST_BUILD_DIR}":${LD_LIBRARY_PATH}
 "${build_dir}"/TestFoundation/TestFoundation
--

Miscompile?

 - Daniel

> On Apr 29, 2016, at 4:58 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10-long-test [#70]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10-long-test/70/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10-long-test
> Date of build:Fri, 29 Apr 2016 16:39:13 -0700
> Build duration:   19 min
> Tests: 
> 
> Name: Swift
> Failed: 0 test(s), Passed: 7877 test(s), Total: 7877 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 291 test(s), Total: 291 test(s)
> 
> Changes
> 
> Commit d40171cc31cf285913d045acda6fed036a01b2f3 by daniel_dunbar:
> [CMake] Add support for selecting which bindings to build.
> 
> edit: CMakeLists.txt
> 
> Commit f1b5d2bf37ba6cd10bf7ab4b51877d68eae97cbc by ccross:
> Fix NINJA_STATUS %e on dumb terminals
> 
> edit: src/build.cc 
> Commit af4973d2251bf9bc616ceb5f9d9d64dd948ed569 by ccross:
> Fix NINJA_STATUS %r on dumb terminals
> 
> edit: src/build.h
> edit: src/build_test.cc
> edit: src/build.cc 
> Commit 16e600a6a1c09b9d06238c6a6f0eb4b958487b38 by eeckstein:
> StackPromotion: fix a bug which could place the deallocation inside a
> 
> edit: test/SILOptimizer/stack_promotion.sil
> edit: lib/SILOptimizer/Transforms/StackPromotion.cpp
> 
> Commit e3dc3e2fd2a06df2dda7d3cdc38210d2460e5764 by eeckstein:
> SIL: remove an assert which checks that an operand value cannot be the
> 
> edit: include/swift/SIL/SILValue.h
> 
> Commit a5aa22565e62bdd447eb3441ac4a6cc3d7e5e21e by gribozavr:
> stdlib: simplify LazyFilterCollection
> 
> edit: stdlib/public/core/Filter.swift.gyb
> 
> Commit 225b94ad0964bcf36577bac4b86772ab8343112a by jgroff:
> Further refinement of `isBindableTo` for BoundGenericType conformances.
> 
> edit: lib/AST/Type.cpp
> 
> Commit 53bb3e8ea10f574510c8622f713f479fe9620e47 by eeckstein:
> SimplifyCFG: improve switch_enum simplification.
> 
> edit: lib/SILOptimizer/Transforms/SimplifyCFG.cpp
> edit: test/SILOptimizer/simplify_cfg.sil
> 
> Commit 66c4c87aae2b9a9c4d6a2a7eb36d0660397fca81 by modocache:
> [Runtime] Android does not support constexpr
> 
> edit: include/swift/Runtime/MutexPThread.h
> 
> Commit d00dddbdabe448642524cbd684d7996ada04d384 by moiseev:
> [stdlib][swift-3-indexing-model] fixing the ReversedCollection/lazy test
> 
> edit: 
> stdlib/private/StdlibCollectionUnittest/CheckCollectionInstance.swift.gyb
> edit: validation-test/stdlib/Lazy.swift.gyb
> edit: stdlib/public/core/ClosedRange.swift
> 
> Commit ef4249bbc4bdbc9f37375e83c033f3599b9ed0e8 by gribozavr:
> stdlib: set the right displayStyle in Optional's Mirror
> 
> edit: test/1_stdlib/Optional.swift
> edit: test/IDE/complete_generic_optional.swift
> edit: test/1_stdlib/Reflection.swift
> edit: stdlib/public/core/Optional.swift
> 
> Commit 01d4fd5a2fa6bbda8f0c9de7fc63ca846b7f11db by egranata:
> This code is supposed to fail when the read fails. Make it so
> 
> edit: lib/RemoteAST/RemoteAST.cpp
> 
> Commit d525b8320bbbe769a4ca4cc8f8028a43a70cdac9 by daniel_dunbar:
> [build-script] Don't try to build llbuild Swift bindings as part of
> 
> edit: utils/build-script-impl
> 
> Commit 5594fc5339cef82f1999513412fb54b7ae92c881 by dfarler:
> Collect builtins referenced by captures
> 
> edit: lib/IRGen/GenReflection.cpp
> 
> Commit 8f06358b5bbae0fde8676071c5206cf0c4607405 by spestov:
> Reflection: Fix typos
> 
> edit: include/swift/Reflection/ReflectionContext.h
> edit: stdlib/public/SwiftRemoteMirror/SwiftRemoteMirror.cpp
> 
> Commit 0273167b5d22f2c7efd17293c9b492c654e12206 by rjmccall:
> Use the known type parameters to determine static offsets to stored
> 
> edit: test/RemoteAST/member_offsets.swift
> edit: lib/IRGen/StructLayout.h
> edit: test/IRGen/class.sil
> edit: test/IRGen/fulfillment.sil
> edit: lib/IRGen/GenType.h
> edit: test/IRGen/generic_classes.sil
> edit: lib/IRGen/GenClass.cpp
> edit: test/IRGen/subclass.swift
> edit: lib/IRGen/GenType.cpp
> edit: test/IRGen/sil_witness_methods.sil
> edit: test/IRGen/partial_apply_forwarder.sil
> 
> Commit 1bd536e5772835a9c454c0fb4560f5ee90aa4e3d by spestov:
> Reflection: Fix compile error, oops
> 
> edit: include/swift/Reflection/ReflectionContext.h
> 
> Commit 1d5b9b09ace6f4dd2c84066c36b8d54bc4b3c54f by spestov:
> Reflection: Add instance-specific layout entry point, and do some
> 
> edit: 

Re: [swift-dev] hmap files

[Daniel Dunbar via swift-dev]

Yes, you should avoid passing header map files.

They should only be used when trying to integrate with existing Xcode projects, 
when invoking swiftc yourself you should use the simpler header search path 
options (-I, -F).

 - Daniel

> On Apr 26, 2016, at 11:51 AM, Rafkind, Jon  wrote:
> 
> Well I'm wondering what to do with them since I am writing a program
> that directly invokes the swift compiler code. Meaning, I create a
> swift::Module*, call swift::parseIntoSourceFile,
> swift::performTypeChecking, etc. So far it doesn't seem that I need to
> pass along the hmap files to anything in the swift codebase, perhaps the
> hmap files I see xcode adding to the swiftc lines so far are all
> superfluous.
> 
> On 04/26/2016 11:46 AM, Daniel Dunbar wrote:
>> They are "header map" files and you are right they are very poorly 
>> documented.
>> 
>> Xcode uses them to provide the compiler with a mapping of textual include 
>> names to actual file paths.
>> 
>> What are you specifically looking into?
>> 
>> - Daniel
>> 
>>> On Apr 26, 2016, at 11:42 AM, Rafkind, Jon via swift-dev 
>>>  wrote:
>>> 
>>> What are hmap files and how do they relate to the swift compilation
>>> process? It seems that they are a clang thing, but I can't find any
>>> documentation on them.
>>> ___
>>> 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] hmap files

[Daniel Dunbar via swift-dev]

They are "header map" files and you are right they are very poorly documented.

Xcode uses them to provide the compiler with a mapping of textual include names 
to actual file paths.

What are you specifically looking into?

 - Daniel

> On Apr 26, 2016, at 11:42 AM, Rafkind, Jon via swift-dev 
>  wrote:
> 
> What are hmap files and how do they relate to the swift compilation
> process? It seems that they are a clang thing, but I can't find any
> documentation on them.
> ___
> 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 Failure: 0. OSS - Swift Incremental RA - OS X (master) #3634

[Daniel Dunbar via swift-dev]

Mishal, I believe this failed because this builder doesn't have the swiftpm 
source checked out, even though it does for Linux (and the @swift-ci test 
builders do, apparently).

Can you update the Jenkins config to also checkout out the OSS 
apple/swift-package-manager? I will revert in the meantime.

 - Daniel

> On Apr 25, 2016, at 4:28 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#3634]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/3634/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Mon, 25 Apr 2016 16:26:26 -0700
> Build duration:   1 min 57 sec
> 
> Changes
> 
> Commit d3373dccd32af057fafa0982a55edd21f0c4d83c by daniel:
> Swift binding integration (#23)
> 
> edit: tests/lit.site.cfg.in
> add: cmake/modules/FindSwiftc.cmake
> edit: tests/Examples/lit.local.cfg
> add: tests/Examples/swift-bindings/core/basic.txt
> edit: tests/CMakeLists.txt
> edit: products/swift-bindings/CMakeLists.txt
> edit: CMakeLists.txt
> edit: tests/lit.cfg
> edit: products/swift-bindings/llbuild.swift
> edit: cmake/modules/Utility.cmake
> add: examples/swift-bindings/core/basic.swift
> 
> Commit 5469d9f8d2eb5a598b99f7766bf5b0f52f5196e4 by daniel_dunbar:
> [build-presents] Enable SwiftPM in incremental OS X builds.
> 
> edit: utils/build-presets.ini
> 
> Commit 825e02e2f114e3bf7729afa09c182468f0f3087d by jgroff:
> Remove -enable-import-objc-generics staging flag.
> 
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: include/swift/Basic/LangOptions.h
> edit: lib/Frontend/CompilerInvocation.cpp
> edit: include/swift/Option/FrontendOptions.td
> 
> Commit 20e1131b5689edc5077132a28bd25b959328026b by dgregor:
> [Linux] This test requires Objective-C interoperability.
> 
> edit: test/IRGen/newtype.swift

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

Re: [swift-dev] Swift incremental compile profiling

[Daniel Dunbar via swift-dev]

> On Apr 24, 2016, at 3:19 PM, Samantha John via swift-dev 
>  wrote:
> 
> Hello List (cc/Jordan),  
> 
> At a high level: Brian and I are looking into contributing to incremental 
> compilation in Swift. Right now we're trying to do an incremental compile by 
> invoking swiftc. 
> 
> Our understanding so far:
> - swiftc takes a list of input files. 
> - If swiftc is invoked with '-incremental', it requires an '-output-file-map' 
> option to also be passed. We assume this is used to determine where 
> intermediate dependency files go.
> - Looking at the tests in test/Driver/Dependencies/Inputs and the sorts of 
> files Xcode generates when building Swift projects, we determined 
> '-output-file-map' to be a JSON file (which is parsed by the llvm yaml 
> parser? 
> https://github.com/apple/swift/blob/95e3be665d9387eb0d354f3d0f313e44c7b4245d/lib/Driver/OutputFileMap.cpp#L100
>  
> ).
>  We tried writing our own, this is the shortest version that the compiler 
> didn't error on:
> 
> ```
> {
>   "": {
> "swift-dependencies": "MyModule-main.swiftdeps"
>   }
> }
> ```
> 
> - When compiling with the above file ('swiftc -incremental -output-file-map 
> OurFileMap.json *.swift'), swiftc writes to MyModule-main.swiftdeps. The end 
> result looks like this:
> 
> ```
> version: "Swift version 3.0-dev (LLVM 752e1430fc, Clang 3987718dae, Swift 
> a2cf18ba2f)"
> options: "9277a78155e85019ce36a3c52e9f3f02"
> build_time: [514847765, 412105000]
> inputs:
>   "Class1.swift": [514841531, 0]
>   "Class2.swift": [514844635, 0]
>   "main.swift": [514841821, 0]
> ```
> 
> - Where the [xxx, yyy] are timestamps with the first number representing 
> seconds, the second nanoseconds. 
> (https://github.com/apple/swift/blob/95e3be665d9387eb0d354f3d0f313e44c7b4245d/lib/Driver/Driver.cpp#L221
>  
> )
> 
> - We invoked 'swiftc -incremental -output-file-map OurFileMap.json *.swift 
> -parseable-output -save-temps' to show us the paths to the generated 
> .swiftdeps files. We assume that to get incremental compiles to work for us, 
> we'd need to pass these generated .swiftdeps files' paths to the compiler 
> somehow. We can't figure out how to do this, so this is the point where our 
> incremental compile fails: 
> https://github.com/apple/swift/blob/95e3be665d9387eb0d354f3d0f313e44c7b4245d/lib/Driver/Compilation.cpp#L348
>  
> 
You don't need to point the compiler at the swiftdeps files, it reuses the ones 
passed in the output file map if -incremental is passed.

You didn't mention it (I don't think) but you also need to pass 
-emit-dependencies, however it sounds like you are doing this.

> This is as far as we got. Would super appreciate if anyone on the list could 
> point us in the right direction from here, especially for the following 
> questions:
> 
> 1. This would probably be easier if we could find the right test case. We 
> poked around in test/Driver/Dependencies which had a bunch of tests around 
> reading the .swiftdeps files, but we couldn't find tests that demonstrated 
> how incremental compilation worked at a high level.
> 
> 2. '-output-file-map': Is this file meant to be written by hand, or is there 
> a part of the swift compiler that writes this for you?

It is meant to be written by the build system which invokes Swift. See also:
  
https://github.com/apple/swift-llbuild/blob/master/lib/BuildSystem/SwiftTools.cpp#L206
which is what the Swift package manager uses (which supports incremental 
compiles).

Your best bet is to take the exact command line used by xcodebuild, and then 
invoke swiftc with that to replicate the incremental build. If you run with -v 
you should be able to see exactly what files get built

HTH!
 - Daniel

> 
> 3. Specifying paths for .swiftdeps: We had assumed this was done based on the 
> '-output-file-map', but writing the paths we wanted manually did not seem to 
> work. Any tips?
> 
> Thanks so much!
> Sam and Brian
> 
> On Wed, Apr 13, 2016 at 5:18 PM, Samantha John  > wrote:
> Hi Jordan, 
> 
> The thing that sticks out in the dependency analysis is the treatment of 
> external dependencies. The entire module has the same list of external 
> dependencies which causes a lot of needless recompiles- especially if you 
> start with a large swift project and slowly start to move things into 
> modules. 
> 
> So to me the lowest hanging fruit would be to only mark files for 
> recompilation that explicitly import the external dependency. This seems 
> pretty safe since you can't compile unless the dependency is explicitly 
> imported. Has anyone on the list tried this before? 
> 
> A second 

Re: [swift-dev] test-repl-glibc failure

[Daniel Dunbar via swift-dev]

I saw that, my question is specifically how this is going to be resolved. We 
shouldn't have failures on the bots with no short term plan.

Are there objections to XFAILing this test until resolved?

 - Daniel

> On Apr 21, 2016, at 10:36 PM, Greg Parker <gpar...@apple.com> wrote:
> 
> 
>> On Apr 21, 2016, at 9:20 PM, Daniel Dunbar via swift-dev 
>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>> 
>> What is the status of the Ubuntu packages CI failure:
>> swift-package-tests :: repl/test-repl-glibc.py
>> 
>> It has been failing for a while now and I would like to get back to being 
>> able to use @swift-ci please test and merge.
> 
> https://bugs.swift.org/browse/SR-1109 <https://bugs.swift.org/browse/SR-1109>
> 
> 
> -- 
> Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime 
> Wrangler
> 
> 

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

[swift-dev] Including `FileCheck` in downloadable toolchains

[Daniel Dunbar via swift-dev]

Hi all,

I would like to propose that we include `FileCheck` in the downloadable 
toolchains.

The downloadable toolchains are quite useful for people who are wanting to work 
on Swift projects that use FileCheck (llbuild, swift-integration-tests), but 
don't want to build everything from scratch. I would suggest it be located in 
'/usr/local/bin', to give some indication that it is a tool somewhat internal 
to the project.

Any objections? The gzipped tool comes to around 150KB, which is a drop in the 
bucket of our current ~200MB archives.

 - Daniel


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

[swift-dev] test-repl-glibc failure

[Daniel Dunbar via swift-dev]

What is the status of the Ubuntu packages CI failure:
swift-package-tests :: repl/test-repl-glibc.py

It has been failing for a while now and I would like to get back to being able 
to use @swift-ci please test and merge.

 - Daniel

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

Re: [swift-dev] Swift modules aware of their version tag on compilation

[Daniel Dunbar via swift-dev]

Have you seen:
  https://github.com/apple/swift-package-manager/pull/122 


Also, please consider starting a new thread instead of replying to the digest 
email (which is very large, and confusing since it includes many topics).

 - Daniel

> On Apr 18, 2016, at 11:07 AM, Robert F Dickerson via swift-dev 
>  wrote:
> 
> I would like to see if the community is interested in the ability for Swift 
> libraries (when built with Swift Package Manager) to be aware of the current 
> tagged version number applied on that library during compilation. This could 
> be useful for when the executable is run, we can know the version of that 
> library dependency so that we can dump that information out to our logs. 
> Perhaps some macro like #file or #line, but something like #version. 
> 
> 
> 
> 
> swift-dev-request---04/18/2016 11:57:30 AM---Send swift-dev 
> mailing list submissions to swift-dev@swift.org
> 
> From: swift-dev-requ...@swift.org
> To: swift-dev@swift.org
> Date: 04/18/2016 11:57 AM
> Subject: swift-dev Digest, Vol 5, Issue 18
> Sent by: swift-dev-boun...@swift.org
> 
> 
> 
> 
> Send swift-dev mailing list submissions to
> swift-dev@swift.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
> or, via email, send a message with subject or body 'help' to
> swift-dev-requ...@swift.org
> 
> You can reach the person managing the list at
> swift-dev-ow...@swift.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swift-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: [SR-710][RFC] Automatically detecting XCTest test methods
>  on Linux: Reflection? SourceKit? (Brian Gesiak)
>   2. Re: R_ARM_GOT_PREL error when building Swift on Pi from
>  source (Timothy Wood)
>   3. Re: R_ARM_GOT_PREL error when building Swift on Pi from
>  source (Joe Bell)
>   4. Re: R_ARM_GOT_PREL error when building Swift on Pi from
>  source (Timothy Wood)
>   5. Random failure when building Swift on Pi (Timothy Wood)
>   6. Re: [SR-710][RFC] Automatically detecting XCTest test methods
>  on Linux: Reflection? SourceKit? (Drew Crawford)
>   7. Re: R_ARM_GOT_PREL error when building Swift on Pi from
>  source (Timothy Wood)
>   8. SIMD in open source Swift? (Geordie Jay)
>   9. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
>  Ubuntu 15.10 (master) #4254 (Sean Callanan)
>  10. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
>  Ubuntu 15.10 (master) #4254 (Sean Callanan)
>  11. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
>  OS X (master) #3432 (Sean Callanan)
> 
> 
> --
> 

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

Re: [swift-dev] quick, spot the UB in this code:

[Daniel Dunbar via swift-dev]

> On Apr 6, 2016, at 9:58 PM, Dmitri Gribenko  wrote:
> 
> On Wed, Apr 6, 2016 at 9:54 PM, Daniel Dunbar  wrote:
>> Could we get a method that takes a [UInt8] directly and performs the same 
>> basic function?
> 
> I think the root of the surprise here is that the compiler converts
> [UInt8] into an unsafe pointer.  This is appropriate when the callee
> is a C API, but usually not appropriate when it is a Swift API.  This
> is not the first time when this implicit conversion causes surprise.
> I think we should discuss scoping that conversion to only C and
> Objective-C calls.

+1 from me.

> But I agree with you, we should have a similar operation that works on
> arbitrary collections.

Cool, thanks.

 - Daniel

> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-dev] quick, spot the UB in this code:

[Daniel Dunbar via swift-dev]

Could we get a method that takes a [UInt8] directly and performs the same basic 
function? In my experience I have frequently wanted such a thing (primarily 
when debugging things) when working with binary protocols that have embedded 
ASCII data.

 - Daniel

> On Apr 6, 2016, at 9:51 PM, Dmitri Gribenko via swift-dev 
>  wrote:
> 
> On Wed, Apr 6, 2016 at 9:16 PM, Drew Crawford via swift-dev
>  wrote:
>> and it should crash
>> deterministically if it gets non-terminated bytes, or
> 
> It can't, how would you check for this, only given a pointer?
> 
>> 2.  It should not require null-terminated bytes
> 
> This operation converts a C string to a Swift string, so (2) is a non-starter.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> ___
> 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] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

[Daniel Dunbar via swift-dev]

> On Apr 3, 2016, at 3:36 PM, Dmitri Gribenko  wrote:
> 
> On Sun, Apr 3, 2016 at 2:11 PM, Brian Gesiak  wrote:
>> I think #2 is the best option. It’s less work than both #1 and #3. I believe
>> logic like IsTestCandidate belongs in libIDE anyway—SourceKit should stick
>> to XPC and asynchronous communication with libIDE.
> 
> I like #3 better (an option to swiftc), because that would decouple
> the test discovery tool from the Swift compiler.  That would allow you
> to use the discovery tool with different compilers.  And, because we
> would avoid statically linking libIDE, it would mean one less copy of
> LLVM, Clang and Swift in the toolchain.

Ultimately my opinion is that it is likely that the package manager will want 
an API interface to Swift in any case. I personally would rather we simply plan 
on that.

I also would like to avoid duplicating anything in the toolchain, but think 
that should be done by moving the driver to sitting on top of a shared library.

>> Not being an expert in many of these components, I have several questions:
>> 
>> I’m assuming the reflection API to return a list of instance methods on a
>> XCTestCase subclass is not ready yet, and won’t be for some time. Is this
>> accurate?
> 
> I think so.
> 
>> I’m assuming that SourceKit is intended to be an asynchronous wrapper over
>> libIDE, and that logic like IsTestCandidate should be moved to libIDE. Is
>> this accurate?
> 
> SourceKit has a lot of functionality of its own, but moving this
> particular piece of logic to libIDE sounds reasonable.
> 
>> I’m assuming that SourceKit is coupled with XPC, and that it would be more
>> work to port it to Linux than it would be to move its logic to libIDE. Is
>> this accurate?
> 
> It is not tightly coupled with XPC, there is a portability layer that
> you could implement for Linux.  You would need to decide on an IPC
> mechanism and serialization format though.

For our purposes, I don't think we need IPC. I think a direct (C) library 
interface would be fine. Clients can implement the IPC/XPC if they need it.

>> If you have thoughts/feedback, please reply to this email or comment on
>> SR-710. Your input would be greatly appreciated!!
> 
> I'm wondering how feasible is it to change the XCTest API to
> accommodate better the Swift language that we have, rather than trying
> to add custom tooling to make the existing API work.  Adding magic
> tooling that adds behavior not present in the language seems unnatural
> to me.

I agree with you that it is unnatural, but I think this ship has sailed for 
XCTest, we have a need to support the existing API in a cross platform manner. 

My personal preference is that eventually we would build features like this on 
top of general support for attributes (a la Java/Python/C#).

> Compare with StdlibUnittest -- by using an API to build tests we get
> the following advantages:
> 
> - We completely avoid having the issue of test discovery, executing
> the code discovers the tests.  No reflection needed!

While I think StdlibUnittest is neat, I also believe that there are very good 
reasons for supporting test discovery in a test suite. I have used these 
features in other suites to great avail to create (bidirectional, sometimes) 
lit bridge adaptors between various test frameworks (Python unittest, 
googletest, XCTest).

In an IDE context, it is also very useful to be able to perform test discovery 
independent of test execution.

As one other example, I've used lit with suites with hundreds of thousands of 
tests... it would be unfortunate to have to dynamically discover all of those 
tests when the user is just trying to run a single one.

> - We can add attributes to tests (for example, skip, xfail).  In the
> current XCTest API this would require adding some kind of user-defined
> attributes, which is another language which is a long way from being
> designed and implemented.

This isn't necessarily the case, XCTest could in theory provide explicit APIs 
to do these things as part of test execution. I agree attributes are a better 
fit in the current model.

> - We can define data-parameterized tests.

> - Tests can be dynamically synthesized by control flow.  In the
> current XCTest API, dynamically generating tests would mean
> dynamically generating methods, which is even more far off than
> read-only method reflection.

FWIW, XCTest has some support for doing these kinds of things, they just don't 
take the form of the pattern-matched methods.

 - Daniel

> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

[Daniel Dunbar via swift-dev]

> On Dec 20, 2015, at 11:26 PM, Nadav Rotem  wrote:
> 
> 
>> On Dec 20, 2015, at 1:01 PM, Daniel Dunbar > > wrote:
>> 
>> Hi Nadav,
> 
> Hi Daniel, 
> 
>> 
>> One thing you didn't call out here was any connection to visibility.
> 
> This is a great point! 
> 
> Apps usually don’t export too many symbols, but they do import symbols from 
> external shared objects and need to keep the long names around. I created a 
> basic Swift one-page iOS App using the Xcode wizard and the generated binary 
> had a string-table of 70K**. The same app in Obj-C had a 12K linkedit section 
> ("size -m" can print this info).

Where was that from, though? I wouldn't expect that many imported symbols in a 
simple app (and in general would expect it to grow maybe logarithmically with 
the size of an application, since it is bounded how many you can import vs. how 
many you can write yourself).

>> I would expect that in practice it is quite common for most of the symbols 
>> to not be visible outside the linkage unit. Inside the linkage unit, the 
>> compiler can already rename many of the symbols in any way it likes. 
>> Wouldn't one tact for solving this problem simply be to encourage more 
>> pervasive use of whole module optimization, and support compiler renaming of 
>> non-exported symbols?
> 
> I don’t think that Swift Access Control (public/internal/private) is affected 
> by WMO, but I will check. 

My point here was that with WMO you can rename all the internal symbols with 
ease.

 - Daniel

> 
> Thanks,
> Nadav
> 
> 
> 
> ** This is one of the names that the sample app has:
> 
> __TTSf4n_s_s_n___TTSg5GVSs12_ArrayBufferPSs9AnyObject__GS_PS0___Ss16_ArrayBufferTypeSs_GVSs15CollectionOfOnePS0___GS2_PS0___Ss14CollectionTypeSs_PS0___GVSs17IndexingGeneratorGS_PS0GS4_GS_PS0Ss13GeneratorTypeSs_PS0___PS0___GVSs12_SliceBufferPS0___GS6_PS0___Ss23_CollectionDefaultsTypeSsGS6_PS0___Ss32_CollectionGeneratorDefaultsTypeSs_GS4_GS6_PS0GS4_GS6_PS0S5_Ss_PS0___SiSiSs16ForwardIndexTypeSs_SiSiSs18_SignedIntegerTypeSs_SiSiSs33_BuiltinIntegerLiteralConvertibleSs_Si_PS0___GVSs14GeneratorOfOnePS0___GS12_PS0___S5_Ss_OSs3BitS13_S9_Ss_SiSiS10_Ss_SiSiS11_Ss_VSs20_DisabledRangeIndex__PS0___GVSs12_prext_SliceGS2_PS0GS15_GS2_PS0S7_SsGS15_GS2_PS0S8_Ss_GS4_GS15_GS2_PS0_GS4_GS15_GS2_PS0_S5_Ss_PS0___S13_S13_S9_Ss_SiSiS10_Ss_SiSiS11_Ss_S14__PS0_TFSs28_arrayNonSliceInPlaceReplaceu0_Rq_Ss16_ArrayBufferTypeq0_Ss14CollectionTypezqq_S_7Elementqqq0_Ss12SequenceType9GeneratorSs13GeneratorType7Elementzqq_Ss23_CollectionDefaultsType5IndexSizqqq_S3_5IndexSs16ForwardIndexType8DistanceSizqqq_S3_5IndexS4_19_DisabledRangeIndexSiz_S3_5IndexS4_8DistanceSs25IntegerLiteralConvertible18IntegerLiteralTypeSi_FTRq_GVSs5RangeSi_Siq0__T_
> 
>> 
>>  - Daniel
>> 
>>> On Dec 18, 2015, at 4:42 PM, Nadav Rotem via swift-dev >> > wrote:
>>> 
>>> Hi Swift-Dev, 
>>> 
>>> We care deeply about the size of binaries that are generated by the Swift 
>>> compiler and make an effort to optimize and shrink the generated binaries. 
>>> One of the problems that we have today is that swift symbols are mangled 
>>> into extremely long strings. This is especially a problem for libraries, 
>>> and almost half of the size of libswiftCore.dylib (the swift runtime 
>>> library on x86_64 OSX) is string tables. On MacOSX you can use the command 
>>> ’size -m file.dylib’ to read the size of the string table.  C++ also 
>>> suffers from the problem of long names, but since we control the Swift ABI 
>>> we can do better than C++.
>>> 
>>> Here are two names that I found in our libraries:
>>> 
>>>  
>>> __TIF14StdlibUnittest13checkSequenceu0_Rxs14CollectionType_s12SequenceTypeWx9Generator7Element_zW_9GeneratorS3__rFTxq_KT_SS9showFrameSb10stackTraceVS_14SourceLocStack4fileSS4lineSu16resiliencyChecksVS_32CollectionMisuseResiliencyChecks9sameValueFTWxS2_S3__WxS2_S3___Sb_T_A6_
>>> 
>>>  
>>> __TTSg5VSS13CharacterViewS_s14CollectionTypes_GVs17IndexingGeneratorS__GS1_S__s13GeneratorTypes_VS_5IndexS3_s16ForwardIndexTypes_SiSis18_SignedIntegerTypes_SiSis33_BuiltinIntegerLiteralConvertibles_Vs20_DisabledRangeIndex__S_S_s9IndexablesS_s12SequenceTypes_GS1_S__GS1_S__S2_s_Vs9Character_S3_S3_S4_s_SiSiS5_s_SiSiS6_s_S7__S__S10__S10TFFSS12replaceRangeuRxs14CollectionTypeWx9Generator7Element_zVs9CharacterrFTGVs5RangeVVSS13CharacterView5Index_4withx_T_U_FRS4_T_
>>> 
>>> One way to solve this problem is to implement a better string table format 
>>> that will include some kind of compression or tree encoding into MachO, ELF 
>>> and PE. The work on MachO, ELF and PE is beyond the scope of the Swift 
>>> project and I’d like to focus on improving things on the Swift side. 
>>> 
>>> I see two independent tasks that we can do to shorten the length of string 
>>> symbols. First, we can improve the existing mangling. We can do things like 
>>> use 

Re: [swift-dev] I can't install swift on ubuntu 14.04 lts

[Daniel Dunbar via swift-dev]

What specific problem do you encounter? Please include logs from the command 
line and the steps you followed.

 - Daniel

> On Dec 6, 2015, at 8:16 AM, Piero Sabino via swift-dev  
> wrote:
> 
> I can't install swift on ubuntu 14.04 lts following the instructions on 
> "www.swift.org".
> 
> ___
> 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