FYI: SwiftGen 0.7.1 generated UIColor.Name type causes linker errors when WMO is enabled

[phatblat]

Updated to SwiftGen 0.7.1 today and started seeing build failures from our app's Release config (which has WMO enabled). Using 0.6 last week the source for the UIColor extension was different and didn't cause this issue.

I'm not expecting a fix as this certainly looks like a compiler issue, but thought I'd log the issue for others to find in case they run across it.

Here is an example project where these errors can be observed.
https://github.com/phatblat/SwiftGenWMO

Undefined symbols for architecture x86_64:
  "direct type metadata for ext.SwiftGenWMO.__ObjC.UIColor.Name", referenced from:
      _globalinit_33_9DB38CA9AF8247CBBD097F938D9B20B4_func0 in ViewController.o
      generic specialization <ext.SwiftGenWMO.__ObjC.UIColor.Name with ext.SwiftGenWMO.__ObjC.UIColor.Name : Swift.Hashable in SwiftGenWMO, Swift.UInt32> of static Swift._VariantDictionaryStorage.maybeGetFromCocoaStorage <A, B where A: Swift.Hashable> (Swift._VariantDictionaryStorage<A, B>.Type)(Swift._CocoaDictionaryStorage, forKey : A) -> B? in ViewController.o
      function signature specialization <Arg[1] = Dead> of generic specialization <(ext.SwiftGenWMO.__ObjC.UIColor.Name, Swift.UInt32)> of static Swift.Array._allocateBufferUninitialized <A> ([A].Type)(Swift.Int) -> Swift._ArrayBuffer<A> in ViewController.o
      function signature specialization <Arg[0] = Owned To Guaranteed, Arg[1] = Dead> of generic specialization <ext.SwiftGenWMO.__ObjC.UIColor.Name with ext.SwiftGenWMO.__ObjC.UIColor.Name : Swift.Hashable in SwiftGenWMO, Swift.UInt32> of static Swift._NativeDictionaryStorage.fromArray <A, B where A: Swift.Hashable> (Swift._NativeDictionaryStorage<A, B>.Type)([(A, B)]) -> Swift._NativeDictionaryStorage<A, B> in ViewController.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This has been filed as rdar://23472326

[phatblat]

Note: this issue is only present in the new default colors template. Switching to the rawValue template was sufficient to work around it in our Release builds.

swiftgen colors \
    --template rawValue \
    --output ${PROJECT_NAME}/Resources/SwiftGen/UIColor+Name.swift \
    ${PROJECT_NAME}/Resources/Colors.txt

[AliSoftware]

Ah, interesting, thanks for logging.

[AliSoftware]

FYI I tested your sample project in the radar and it still fails with Xcode 7.1.1 (7B1005). You might want to update your radar.

[phatblat]

Done. This issue is also present in Xcode 7.2 beta 3 (7C62)

[AliSoftware]

For reference: https://twitter.com/jckarter/status/668500028269326340

For the Colors I found another workaround (using a switch instead of a dictionary) I'll commit that soon, but for storyboard I'm not sure that'll work

[phatblat]

nice!

[AliSoftware]

@phatblat Is the bug really fixed? I got a coworker telling me that they just encountered that bug (even after ef7fdd4 trying to fix it)… and they're using Xcode 7.3

[phatblat]

I can't reproduce this issue in an app using SwiftGen by switching from the rawValue template back to default. Interestingly, I also can't reproduce this issue in my example project for the radar in any version of Xcode from 7.3 back to 7.1. Not sure what's going on here since it was so easy to reproduce before.

[phatblat]

Ah, I have a run script in the example project that is running SwiftGen and changing the UIColor+Name.swift file

I get the same linker error now in Xcode 7.3 in the example project as long as I don't let SwiftGen 0.8 run to update that file. Using v0.8 and the default color template does not cause any issues.