I've also come up with a small repro case that shows the duplicated
bridging header work: https://bugs.swift.org/browse/SR-3338.
Thanks!
Ben
On Fri, Dec 2, 2016 at 3:28 PM, Ben Asher wrote:
> Filed the issues I ran into with repro cases here:
>
> https://bugs.swift.org/browse/SR-3319
> https:/
Filed the issues I ran into with repro cases here:
https://bugs.swift.org/browse/SR-3319
https://bugs.swift.org/browse/SR-3321
SR-3321 covers the SIL verification failure. The assertion failure was in
the same file as the one that repro'd the SIL verification failure, but I'm
not seeing it anymor
Sure thing! I’ll see if I can put small reproducers together tomorrow.
Ben
On Thu, Dec 1, 2016 at 7:08 PM, Mark Lacey wrote:
>
> On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev
> wrote:
>
> The build failed compiling 3 files in our project. Our app is crashing
> that snapshot; here is some
> On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev
> wrote:
>
> The build failed compiling 3 files in our project. Our app is crashing that
> snapshot; here is some output from the failures:
It would be awesome if you could come up with small reproducers for these and
open bugs for them.
The build failed compiling 3 files in our project. Our app is crashing that
snapshot; here is some output from the failures:
- Assertion failed: (newType == type || (isa(newType) &&
cast(newType)->getNumElements() == 1 &&
cast(newType).getElementType(0) == type)), function rewriteType,
file /Users
I'm trying out DEVELOPMENT-SNAPSHOT-2016-11-29-a now. It's still going, so
I don't have any time results yet. But, I did notice something new (or
maybe existed before but didn't have this warning to expose it). For every
Swift file that's compiled (only using -Onone here), it outputs the same 2
war
Sure! Thanks for reminding me. I'll follow up on that, test, and get back
to you.
Ben
On Thu, Dec 1, 2016 at 2:48 PM, Mark Lacey wrote:
>
> On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev
> wrote:
>
> Just running a quick trial before and after I made this change in our
> project, we were
> On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev
> wrote:
>
> Just running a quick trial before and after I made this change in our
> project, we were previously seeing builds of our main target that took just
> under 13min. With this hack, a clean debug build takes about 4.5min.
You ma
Just running a quick trial before and after I made this change in our
project, we were previously seeing builds of our main target that took just
under 13min. With this hack, a clean debug build takes about 4.5min.
Ben
On Thu, Dec 1, 2016 at 1:33 PM, Ben Asher wrote:
> Okay I think that worked!
Okay I think that worked! And just to clarify, you meant set
SWIFT_OPTIMIZATION_LEVEL = -Owholemodule and OTHER_SWIFT_FLAGS = -Onone ?
I'll file a radar this afternoon with some details and DM you the number.
Thanks again!
Ben
On Thu, Dec 1, 2016 at 1:10 PM, Jordan Rose wrote:
> Xcode needs t
Xcode needs to know that you're building in WMO mode, so rather than putting
-whole-module-optimization in your "Other Swift Flags", put -Onone there. It's
an ugly hack but it should work in the near term.
We do want to work to make this drastic speed difference go away, so if you're
able we (a
Hello! Someone recently tipped me off to using -whole-module-optimization
flag with -Onone for use during debug builds to speed up compile times. In
our project, the speedup feels quite dramatic, but when it gets to the
linking step (after compiling both Swift and Obj-C in the project) it fails
bec
12 matches
Mail list logo
