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

> On Oct 4, 2016, at 1:04 PM, John McCall wrote: > >> >> On Sep 30, 2016, at 11:54 PM, Michael Gottesman via swift-dev >> > wrote: >> >> The document attached below contains the first "Semantic ARC" mini proposal: >> the

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

> On Oct 5, 2016, at 3:37 PM, Ben Asher wrote: > > I just tried with both Xcode 8.1 beta 2 and Xcode 8.0, and 8.1b2 seems maybe > 15s faster (to build our main huge target): 7m28s compared to 7m43s. It's > some improvement, but I'm not exactly sure what kind of

Re: [swift-dev] [swift-lldb-dev] Building and running swift-lldb from Xcode not working :(

> On Oct 5, 2016, at 3:20 PM, Rex Fenley via swift-lldb-dev > wrote: > > I'm using the most recent cmake. I also blew away the lldb directory and > tried to rebuild but still ended up with "error: unknown setting: > cmark-cmake-options" when building desktop :( >

Re: [swift-lldb-dev] Building and running swift-lldb from Xcode not working :(

> On Oct 5, 2016, at 3:20 PM, Rex Fenley via swift-lldb-dev > wrote: > > I'm using the most recent cmake. I also blew away the lldb directory and > tried to rebuild but still ended up with "error: unknown setting: > cmark-cmake-options" when building desktop :( >

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

I just tried with both Xcode 8.1 beta 2 and Xcode 8.0, and 8.1b2 seems maybe 15s faster (to build our main huge target): 7m28s compared to 7m43s. It's some improvement, but I'm not exactly sure what kind of improvement was expected. Is there any profiling/tracing you all would recommend to help

[swift-lldb-dev] Building and running swift-lldb from Xcode not working :(

Hey swift lldb team! I tried building the LLDB target from within Xcode. However, I get the following error during compilation: subprocess.CalledProcessError: Command '['python', '/Users/Rex/Documents/ projects/swift-lldb/llvm/tools/swift/utils/build-script', '--preset=LLDB_Swift_ReleaseAssert',

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

I didn't know about that warning, so thanks for sharing that! Having this enabled will help somewhat, at least in terms of keeping specific slow-to-compile functions out of our master branch. That said, I understand Jordan's response (in SR-2741) of being "leery of 'productizing'" these flags.

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev > wrote: > > Hello! I work with a large project (~900 .swift files and more .m files). We > have a nightly job that compiles the app and calls out function bodies (using > -debug-time-function-bodies) that are slower

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

Hi Ben, I'd really like to see improvements here as well. I don't know what reports would be useful to the Swift team, but allow me to point out https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea75bc09cbd5, which adds a -warn-long-function-bodies option that you may be able to

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

Aha, so the second bug is because home-built toolchains have assertions on by default and Xcode GM toolchains generally have them off. (Not a promise, but true of the last few Xcodes.) Of course, if you hit an assertion failure, there’s no telling what the no-asserts build is actually doing.

Re: [swift-corelibs-dev] [swift-users] Linux - Calendar date(byAdding:to:wrappingComponents:) returns nil when it shouldn't?

> On 5 Oct 2016, at 16:48, Alex Blewitt via swift-users > wrote: > > >> On 4 Oct 2016, at 20:10, Jason Ji via swift-users > > wrote: >> >> Hello, >> >> I'm having an issue with (NS)Calendar on Linux which I think

[swift-dev] Reporting/Debugging Slow Swift Compile Time

Hello! I work with a large project (~900 .swift files and more .m files). We have a nightly job that compiles the app and calls out function bodies (using -debug-time-function-bodies) that are slower than 100ms to compile. Since upgrading to Swift 3, the number of trouble function bodies has one