xcodebuild fails to build swift-asn1 with 'self' used before 'self.init' errors

[adamkornafeld]

Trying to use swift-asn1 as a SPM dependency in an iOS project.

• Using Xcode’s GUI: The project builds successfully.

• Using xcodebuild: The build fails with the following errors:

  .build/SourcePackages/checkouts/swift-asn1/Sources/SwiftASN1/ASN1.swift:95:29: error: 'self' used before 'self.init' call or assignment to 'self'
              self.identifier = identifier
                              ^
  .build/SourcePackages/checkouts/swift-asn1/Sources/SwiftASN1/ASN1.swift:96:24: error: 'self' used before 'self.init' call or assignment to 'self'
              self.depth = depth
                         ^
  .build/SourcePackages/checkouts/swift-asn1/Sources/SwiftASN1/ASN1.swift:97:32: error: 'self' used before 'self.init' call or assignment to 'self'
              self.isConstructed = isConstructed
                                 ^
  .build/SourcePackages/checkouts/swift-asn1/Sources/SwiftASN1/ASN1.swift:98:31: error: 'self' used before 'self.init' call or assignment to 'self'
              self.encodedBytes = encodedBytes
                                ^
  .build/SourcePackages/checkouts/swift-asn1/Sources/SwiftASN1/ASN1.swift:99:28: error: 'self' used before 'self.init' call or assignment to 'self'
              self.dataBytes = dataBytes
                             ^
  .build/SourcePackages/checkouts/swift-asn1/Sources/SwiftASN1/ASN1.swift:100:9: error: 'self.init' isn't called on all paths before returning from initializer
          }
          ^
  .build/SourcePackages/checkouts/swift-asn1/Sources/SwiftASN1/ASN1.swift:139:24: error: 'self' used before 'self.init' call or assignment to 'self'
              self.nodes = nodes
                         ^
  

What I’ve found so far:
From what I can tell, the issue seems related to the use of @inline on initializer functions. I’ve tried comparing build settings between the GUI and command line but couldn’t find any differences that explain the behavior.

Environment:

• Swift 6.0
• Xcode version: 16.2
• macOS version: 15.5

Command used:

xcodebuild build \
	-configuration Release \
	-scheme 'MyApp' \
	-sdk iphoneos \
	-destination 'generic/platform=iOS' \
	-derivedDataPath "$(PWD)/.build" \
	SKIP_INSTALL=NO \
	BUILD_LIBRARY_FOR_DISTRIBUTION=YES

Question:
Do you have any insights into why this happens with xcodebuild but not when building through Xcode’s GUI?

Thanks for maintaining this repo, it's great!

[Lukasa]

Yeah, this is the result of BUILD_LIBRARY_FOR_DISTRIBUTION=YES. That's not a flag we support using to build swift-asn1. We would accept a patch that makes that build work, but we aren't going to guarantee we won't break it again, and we don't promise that swift-asn1 maintains a stable ABI (in fact, I'm quite sure it doesn't).

[iKenndac]

@Lukasa Is a fix for this still something you'd accept?

We've just hit this and it's a fairly big blocker. Update: Solved for us, see below. Our situation is that we're shipping a framework SDK project with BUILD_LIBRARY_FOR_DISTRIBUTION enabled, but swift-asn1 is being linked in statically. We're shipping a stable ABI to our clients, but the API/ABI between versions of swift-asn1 can change no problem.

[Lukasa]

Yes, we'd accept the fix, we just won't promise it won't regress.

Conceptually you should be able to statically link this in without setting BUILD_LIBRARY_FOR_DISTRIBUTION so long as you only use private or internal imports.

[iKenndac]

I do note that you're not open to removing inlineable code, so we might be stuck: #90

I'll investigate using private imports - it's not a feature I've used before. We're actually getting at swift-asn1 via swift-crypto, so perhaps I'd also be stuck there.

[Lukasa]

I don't think that inlinable is inherently your issue: this is mostly a code layout problem. Inlinable is only a problem for a stable ABI, which we don't have. Typically the way to solve this is to create a memberwise initializer that is trivial, and then have all the other initializers funnel into it.

[iKenndac]

Alright, thanks for your reply - I'll investigate solutions and see what I can come up with!

[iKenndac]

Private imports and a slight structure change ended up solving the problem for us, so this is no longer an issue. I'll correct my initial message, but keep the conversation here if others come across it and find it useful.

Our project structure is like this:

OurPublicSDK
    → import OurCoolModule
        → import Crypto
            → import SwiftASN1

We did two things. First, we changed our first import to:

OurPublicSDK
    → private import OurCoolModule
        → import Crypto
            → import SwiftASN1

Second, we moved the BUILD_LIBRARY_FOR_DISTRIBUTION parameter out of the command-line xcodebuild invocation and into the target settings for our public SDK.

These two things solved the issue, as far as I can tell so far. Thanks for the help @Lukasa, somehow I'd managed to get this far without knowing about private imports!

[Lukasa]

Awesome, that's great to hear! I'm glad you got this all working for you.

[JHeisecke]

I made a PR to solve this issue (I've been having with many of apple's libraries) but just now stumbled upon this specific thread. I'll try the same solution. But the PR still stands if valid #122