Rxswift: Xcode 10 GM: Use of unresolved identifier 'CGRectType'

Created on 13 Sep 2018  ·  15Comments  ·  Source: ReactiveX/RxSwift

Short description of the issue:

RxCocoa won't compile with Xcode GM 10 when building for Generic iOS Device, or for an actual device, with three errors:

  • Use of unresolved identifier 'CGRectType'
  • Use of unresolved identifier 'CGPointType'
  • Use of unresolved identifier 'CGSizeType'

Expected outcome:

Successful compilation

What actually happens:

Compilation error. Looking at the build log, I see:

CompileSwift normal arm64_32 <redacted>/Pods/RxCocoa/RxCocoa/Foundation/KVORepresentable+CoreGraphics.swift (in target: RxCocoa-watchOS)
    cd <redacted>/Pods
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend ... -aarch64-use-tbi ...

Notice the arm64_32 and arch64-use-tbi architectures.

I guess that this is why this snippet of KVORepresentable+CoreGraphics.swift does not define the CGRectType, CGPointType, and CGSizeType constants:

#if arch(x86_64) || arch(arm64)
    let CGRectType = "{CGRect={CGPoint=dd}{CGSize=dd}}"
    let CGSizeType = "{CGSize=dd}"
    let CGPointType = "{CGPoint=dd}"
#elseif arch(i386) || arch(arm)
    let CGRectType = "{CGRect={CGPoint=ff}{CGSize=ff}}"
    let CGSizeType = "{CGSize=ff}"
    let CGPointType = "{CGPoint=ff}"
#endif

RxSwift/RxCocoa/RxBlocking/RxTest version/commit

RxCocoa (4.2.0) installed with CocoaPods

Platform/Environment

  • [ ] iOS
  • [ ] macOS
  • [ ] tvOS
  • [x] watchOS
  • [ ] playgrounds

How easy is to reproduce? (chances of successful reproduce after running the self contained code)

I don't know if this is reproducible, considering I'm opening this issue hours after the release of Xcode 10 GM.

Xcode version:

Version 10.0 (10A254a)

Installation method:

  • [X] CocoaPods
  • [ ] Carthage
  • [ ] Git submodules

I have multiple versions of Xcode installed:
(so we can know if this is a potential cause of your issue)

  • [X] yes (Xcode 10 GM in /Applications, and many many many other versions in dedicated folders)
  • [ ] no

Most helpful comment

Any chance the PR will be merged and a new release will be made with the fix? We're under the gun to ship an iOS 12 build as soon after iOS 12 goes public. I understand this late-breaking change from Apple throws a wrench into plans, but anything that can be done here to make this happen ASAP will be greatly appreciated!

All 15 comments

This patch to KVORepresentable+CoreGraphics.swift removes the compilation errors:

-#if arch(x86_64) || arch(arm64)
+#if arch(x86_64) || arch(arm64) || arch(arm64_32)

Note: I don't understand anything to this issue, and I don't know if this is the correct fix. I just have a few apps to ship 😅

The more I look at it, the more I think it is related to the release of Apple Watch Series 4.

Is this on the latest master? asking since we haven't cut a new release since.

I can confirm this error against the latest master hash. We had no problem building with Xcode 10 beta 6, which was the latest version of Xcode 10 prior to yesterday's GM release. I am running carthage archive to pre-package the binaries, but also see it if I let Carthage build RxSwift as part of a normal bootstrap. A full set of errors is as follows:

/Users/.../Development/RxSwift/RxCocoa/RxCocoa.swift:135:48: warning: string interpolation produces a debug description for an optional value; did you mean to make this explicit?
        rxFatalError("Failure converting from \(value) to \(T.self)")
                                               ^~~~~~~
/Users/.../Development/RxSwift/RxCocoa/RxCocoa.swift:135:49: note: use 'String(describing:)' to silence this warning
        rxFatalError("Failure converting from \(value) to \(T.self)")
                                               ~^~~~~~
                                                String(describing:  )
/Users/.../Development/RxSwift/RxCocoa/RxCocoa.swift:135:49: note: provide a default value to avoid this warning
        rxFatalError("Failure converting from \(value) to \(T.self)")
                                               ~^~~~~~
                                                      ?? <#default value#>
/Users/.../Development/RxSwift/RxCocoa/Foundation/KVORepresentable+CoreGraphics.swift:31:38: error: use of unresolved identifier 'CGRectType'
        if strcmp(KVOValue.objCType, CGRectType) != 0 {
                                     ^~~~~~~~~~
CoreGraphics.CGRectEdge:1:13: note: did you mean 'CGRectEdge'?
public enum CGRectEdge : UInt32 {
            ^
CoreGraphics.CGRectMake:3:13: note: did you mean 'CGRectMake'?
public func CGRectMake(_ x: CGFloat, _ y: CGFloat, _ width: CGFloat, _ height: CGFloat) -> CGRect
            ^
/Users/.../Development/RxSwift/RxCocoa/Foundation/KVORepresentable+CoreGraphics.swift:45:38: error: use of unresolved identifier 'CGPointType'
        if strcmp(KVOValue.objCType, CGPointType) != 0 {
                                     ^~~~~~~~~~~
CoreGraphics.CGPointMake:3:13: note: did you mean 'CGPointMake'?
public func CGPointMake(_ x: CGFloat, _ y: CGFloat) -> CGPoint
            ^
CoreGraphics.CGPointZero:4:12: note: did you mean 'CGPointZero'?
public let CGPointZero: CGPoint
           ^
/Users/.../Development/RxSwift/RxCocoa/Foundation/KVORepresentable+CoreGraphics.swift:59:38: error: use of unresolved identifier 'CGSizeType'
        if strcmp(KVOValue.objCType, CGSizeType) != 0 {
                                     ^~~~~~~~~~
CoreGraphics.CGSizeMake:3:13: note: did you mean 'CGSizeMake'?
public func CGSizeMake(_ width: CGFloat, _ height: CGFloat) -> CGSize
            ^
Foundation.NSFileType:2:12: note: did you mean 'NSFileType'?
public let NSFileType: FileAttributeKey
           ^
CoreGraphics.CGSizeZero:4:12: note: did you mean 'CGSizeZero'?
public let CGSizeZero: CGSize

I see the same issue (RxCocoa 4.2.0, Xcode GM on High Sierra, Carthage) on the watchOS target. carthage update --platform 'iOS' mitigates the issue for me — I currently don’t need watchOS support.

ah, bummer, I do need watchOS support, hopefully this can be fixed soon!

The patch @groue mentioned does solve the build issue but I'm really confused as to why a bridged 32bit ARM would be needed here at all. 🤔

@kzaher Any thoughts? This would be good to fix on this upcoming release since it seems to be a new regression for Xcode 10 GM (Yay, Apple! 🍎 )

Definitely watchOS 5 related. See similar WebKit issue: https://bugs.webkit.org/attachment.cgi?id=328501&action=diff

Ok, dug a bit deeper into this, gonna make a PR.

PR is up!

PR makes sense to me, thanks @freak4pc. I think it's not a regression but the addition of a new watch CPU in the Series 4 device announced yesterday.

Yup, indeed. Called it a regression since it only came up in GM (and not beta 6).

Any chance the PR will be merged and a new release will be made with the fix? We're under the gun to ship an iOS 12 build as soon after iOS 12 goes public. I understand this late-breaking change from Apple throws a wrench into plans, but anything that can be done here to make this happen ASAP will be greatly appreciated!

I’m hoping kruno will get to gather a release and merge that PR over the next few days

Same here. Please, merge this PR :)

Was this page helpful?
0 / 5 - 0 ratings