When generating .swiftinterface files using the -emit-module-interface flag, unexpected #if blocks are often generated. For example:
public struct AppStore: Sendable, Codable {
public var storeURL: URL?
public init(storeURL: URL?) {
self.storeURL = storeURL
}
}
- Generated
.swiftinterface
public struct AppStore : Swift.Sendable, Swift.Codable {
public var storeURL: Foundation.URL?
#if compiler(>=5.3) && $NonescapableTypes
public init(storeURL: Foundation.URL?)
#endif
public func encode(to encoder: any Swift.Encoder) throws
public init(from decoder: any Swift.Decoder) throws
}
The Problem
The exact reason for this behavior is unclear, but expressions like #if compiler(>=5.3) && $NonescapableTypes appear in various places within generated interfaces.
Currently, Swift2JavaVisitor ignores IfConfigDecl entirely.
As a result, any method or property signatures wrapped in these #if blocks are lost.
Proposed Solution
We could potentially use SwiftIfConfig to evaluate these blocks.
Although providing a full BuildConfiguration might be complex, it would be highly beneficial to at least support simple, common patterns.
When generating
.swiftinterfacefiles using the-emit-module-interfaceflag, unexpected#ifblocks are often generated. For example:.swift.swiftinterfaceThe Problem
The exact reason for this behavior is unclear, but expressions like
#if compiler(>=5.3) && $NonescapableTypesappear in various places within generated interfaces.Currently,
Swift2JavaVisitorignoresIfConfigDeclentirely.As a result, any method or property signatures wrapped in these
#ifblocks are lost.Proposed Solution
We could potentially use SwiftIfConfig to evaluate these blocks.
Although providing a full BuildConfiguration might be complex, it would be highly beneficial to at least support simple, common patterns.