> 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
