> On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev <swift-dev@swift.org> 
> 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. Alternately, opening a radar with the full project attached 
will give us an opportunity to get these fixed ASAP!

Mark

> 
> - Assertion failed: (newType == type || (isa<TupleType>(newType) && 
> cast<TupleType>(newType)->getNumElements() == 1 && 
> cast<TupleType>(newType).getElementType(0) == type)), function rewriteType, 
> file /Users/buildn
> ode/jenkins/workspace/oss-swift-package-osx/swift/lib/SILGen/RValue.h, line 
> 207.
> 
> - SIL verification failed: method's Self parameter should be constrained by 
> protocol: selfRequirement.getKind() == RequirementKind::Conformance && 
> selfRequirement.getFirstType()->isEqual(selfGenericParam) && selfR
> equirement.getSecondType()->getAs<ProtocolType>() ->getDecl() == protocol
> 
> We're not getting all the way to linking, but compiling everything for that 
> snapshot took ~11min45s. Based on that, it appears that about a minute is 
> saved with the new fixes since the Swift 3.0 that shipped with Xcode 8.1 (App 
> Store).
> 
> With Xcode 8.2 Beta 2, the app builds fine, and it takes about 12m15s. If 
> Xcode 8.2 Beta 2 also has those fixes that we expect to speed up the build, 
> the extra time here (compared to the snapshot) could be explained by linking, 
> signing, and a few other custom builds scripts that run after compiling.
> 
> Thanks everyone for your help!
> 
> Ben
> 
> 
> On Thu, Dec 1, 2016 at 4:16 PM, Ben Asher <benashe...@gmail.com 
> <mailto:benashe...@gmail.com>> wrote:
> 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 warnings 
> (easy to fix, but not related to any of this) from the same method in the 
> same Obj-C header referring to the arguments and the return types in that 
> method:
> 
> - "array parameter is missing a nullability type specifier (_Nonnull, 
> _Nullable, or _Null_unspecified)"
> - "inferring '_Nonnull' for pointer type within array is deprecated"
> 
> Here's an example of what this method looks like:
> 
> + (NSSet<SomeObject *> *)setWithSELs:(SEL[])sels count:(NSUInteger)count;
> 
> Could this point to more duplicated work?
> 
> Ben
> 
> On Thu, Dec 1, 2016 at 2:50 PM, Ben Asher <benashe...@gmail.com 
> <mailto:benashe...@gmail.com>> wrote:
> 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 <mark_la...@apple.com 
> <mailto:mark_la...@apple.com>> wrote:
> 
>> On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev <swift-dev@swift.org 
>> <mailto:swift-dev@swift.org>> 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 may find that recent snapshot builds from swift.org <http://swift.org/> 
> help with your build times even without enabling -Owholemodule. The redundant 
> type checking of synthesized accessors which we talked about a month or two 
> should now be fixed on master, and it would be great to verify that’s the 
> case with your code and to get an idea of how much it improves your build 
> times.
> 
> Mark
> 
>> 
>> Ben
>> 
>> On Thu, Dec 1, 2016 at 1:33 PM, Ben Asher <benashe...@gmail.com 
>> <mailto:benashe...@gmail.com>> wrote:
>> 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 <jordan_r...@apple.com 
>> <mailto:jordan_r...@apple.com>> wrote:
>> 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 (at Apple) would love to have a source drop of your Swift 3 
>> project, for additional data on where the problems are. Mind filing a Radar?
>> 
>> Best,
>> Jordan
>> 
>> 
>> > On Dec 1, 2016, at 11:51, Ben Asher via swift-dev <swift-dev@swift.org 
>> > <mailto:swift-dev@swift.org>> wrote:
>> >
>> > 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 because ld can't find the individual object files that normally get 
>> > emitted during the debug-type build presumably because 
>> > -whole-module-optimization only emits one (and this isn't a normal 
>> > "-Owholemodule"-type build which works fine).
>> >
>> > I can't seem to reproduce this outside of Xcode, but I was curious if 
>> > anyone has tried this and knows of a workaround to get 
>> > -whole-module-optimization to work with -Onone in Xcode?
>> >
>> > I'm currently using Xcode 8.1 (App Store build) and Swift 3 on macOS 
>> > Sierra.
>> >
>> > Thanks!
>> >
>> > Ben
>> > _______________________________________________
>> > swift-dev mailing list
>> > swift-dev@swift.org <mailto:swift-dev@swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-dev 
>> > <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
>> 
>> 
>> 
>> -- 
>> Ben
>> 
>> 
>> 
>> -- 
>> Ben
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-dev>
> 
> 
> 
> -- 
> Ben
> 
> 
> 
> -- 
> Ben
> 
> 
> 
> -- 
> Ben
> _______________________________________________
> 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

Reply via email to