feat(swift) add swift to C++ and objective-C interop#6967
feat(swift) add swift to C++ and objective-C interop#6967waruqi merged 26 commits intoxmake-io:devfrom
Conversation
Summary of ChangesHello @Arthapz, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the build system by introducing robust support for Swift interoperability with C++ and Objective-C. It achieves this by implementing a new rule for automated generation of bridging headers and by deeply integrating Swift compiler tools into the build process. The changes ensure that Swift components can be easily consumed by C++ and Objective-C codebases, facilitating the development of mixed-language projects. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces Swift to C++ and Objective-C interoperability support, which is a significant feature. The changes include a new swift.interop rule for generating C/C++ headers from Swift code, and updates across various toolchain and language definition files to accommodate a new scar tool for Swift static library archiving. The implementation looks solid, but I've found a few potential issues: a correctness bug in a test file that could lead to a crash, a couple of potential nil dereferences in the new Lua rule, and a missing configuration in one of the Xcode toolchain files. Overall, great work on adding this complex feature.
| if x <= 1 { | ||
| return 1 | ||
| } | ||
| return fibonacciSwift(x - 1) + fibonacciSwift(x - 2) |
There was a problem hiding this comment.
The current implementation does not handle negative input values. If a negative number is passed, it will lead to infinite recursion and a stack overflow. It's best to add a check for negative numbers to ensure the function is robust.
if x < 0 {
// Fibonacci of a negative number is not defined.
// The original implementation would lead to infinite recursion.
return 0
}
if x <= 1 {
return 1
}
return fibonacciSwift(x - 1) + fibonacciSwift(x - 2)245ff14 to
94c00aa
Compare
94c00aa to
9a88678
Compare
…y working with objective-c++ sdk
…swift.interop.cxxmain is set (to avoir duplicate main symbols in output binary)
f8c24a0 to
da18615
Compare
c2d14c6 to
44d5134
Compare
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughThis pull request introduces Swift-C++ bidirectional interoperability support to XMake through new test projects, comprehensive toolchain enhancements including Swift interop rules, new compiler toolsets (sc, scsh, scar, scld), and refactored Xcode platform-specific loaders that consolidate configuration logic. Changes
Sequence Diagram(s)sequenceDiagram
participant CppApp as C++ Application
participant CppInterop as C++ Interop Header<br/>(fibonacci-Swift.h)
participant SwiftFib as Swift Function<br/>(fibonacciSwift)
participant CppFib as C++ Function<br/>(fibonacci_cpp)
rect rgb(220, 240, 255)
Note over CppApp,SwiftFib: Unidirectional: C++ calls Swift
CppApp->>CppInterop: call SwiftFibonacci::fibonacciSwift(5)
CppInterop->>SwiftFib: invoke Swift function
SwiftFib-->>CppInterop: return CInt result
CppInterop-->>CppApp: return value to C++
end
rect rgb(240, 220, 255)
Note over CppFib,SwiftFib: Bidirectional: Swift calls C++
SwiftFib->>CppFib: call fibonacci_cpp(x-1)<br/>via extern "C"
CppFib->>SwiftFib: nested call<br/>SwiftFibonacci::fibonacciSwift(x-2)
SwiftFib-->>CppFib: return result
CppFib-->>SwiftFib: return computed value
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧬 Code graph analysis (1)xmake/rules/swift/xmake.lua (5)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
🔇 Additional comments (2)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 10
♻️ Duplicate comments (7)
tests/projects/swift/bidirectional_cxx_interop_lib/test.lua (1)
1-7: Duplicate of comment in tests/projects/swift/cxx_interop/test.lua.This code duplication was already flagged in the review of
tests/projects/swift/cxx_interop/test.lua.tests/projects/swift/cxx_interop_lib/test.lua (1)
1-7: Duplicate of comment in tests/projects/swift/cxx_interop/test.lua.This code duplication was already flagged in the review of
tests/projects/swift/cxx_interop/test.lua.tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.swift (1)
1-7: Duplicate of comment in tests/projects/swift/cxx_interop_lib/lib/fibonacci/fibonacci.swift.This code duplication was already flagged in the review of
tests/projects/swift/cxx_interop_lib/lib/fibonacci/fibonacci.swift.tests/projects/swift/bidirectional_cxx_interop_lib/src/fibonacci.cpp (1)
4-7: Unused parameters in main function.The parameters
argcandargvare declared but never used.Apply this diff:
-int main(int argc, char ** argv) { +int main() { std::cout << SwiftFibonacci::fibonacciSwift(5) << std::endl; return 0; }tests/projects/swift/cxx_interop_lib/src/fibonacci.cpp (1)
4-7: Unused parameters in main function.The parameters
argcandargvare unused.Apply this diff:
-int main(int argc, char ** argv) { +int main() { std::cout << SwiftFibonacci::fibonacciSwift(5) << std::endl; return 0; }tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.cpp (1)
7-7: Incorrect Fibonacci base case for x=0.The base case returns 1 for both x=0 and x=1, but the standard Fibonacci sequence defines F(0) = 0 and F(1) = 1.
Apply this diff:
extern "C" int fibonacci_cpp(int x) { std::cout << "x [cpp]: " << x << std::endl; - if (x <= 1) return 1; + if (x == 0) return 0; + if (x == 1) return 1; return SwiftFibonacci::fibonacciSwift(x - 1) + SwiftFibonacci::fibonacciSwift(x - 2); }xmake/rules/swift/xmake.lua (1)
104-112: Guardsourcefilesin on_prepare_files loop.
sourcebatch.sourcefilescan be nil; wrap withor {}to avoidipairs(nil)error. (Duplicate of earlier feedback.)- local sourcefiles = sourcebatch.sourcefiles + local sourcefiles = sourcebatch.sourcefiles or {}
🧹 Nitpick comments (10)
tests/projects/swift/cxx_interop/test.lua (1)
1-7: Extract duplicated test logic into a shared helper.This exact test function is duplicated in three files:
tests/projects/swift/cxx_interop/test.luatests/projects/swift/bidirectional_cxx_interop_lib/test.luatests/projects/swift/cxx_interop_lib/test.luaConsider extracting this platform-checking logic into a shared test utility module to reduce duplication and improve maintainability.
tests/projects/swift/cxx_interop_lib/lib/fibonacci/fibonacci.swift (1)
1-7: Consider extracting shared Fibonacci implementation.This Fibonacci implementation is duplicated in
tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.swift. While acceptable for test code, extracting it into a shared module would improve maintainability.Note: The exponential time complexity O(2^n) is acceptable for these small test inputs but would be inefficient for larger values.
tests/projects/swift/cxx_interop/src/fibonacci.cpp (2)
4-7: Unused parameters in main function.The parameters
argcandargvare declared but never used in this test program.Apply this diff to remove unused parameters:
-int main(int argc, char ** argv) { +int main() { std::cout << SwiftFibonacci::fibonacciSwift(5) << std::endl; return 0; }
1-7: Code duplication across test projects.This test file is duplicated in three separate test directories:
tests/projects/swift/cxx_interop/src/fibonacci.cpptests/projects/swift/bidirectional_cxx_interop_lib/src/fibonacci.cpptests/projects/swift/cxx_interop_lib/src/fibonacci.cppConsider extracting common test logic into a shared utility or template to reduce maintenance burden.
tests/projects/swift/cxx_interop/lib/fibonacci/fibonacci.swift (1)
1-7: Consider memoization for better performance.The naive recursive implementation has O(2^n) time complexity. While acceptable for demo/test purposes with small inputs, consider adding memoization if this code is used as a reference for users.
xmake/rules/swift/xmake.lua (1)
45-47: Optionally disable rule early to shrink jobgraph.When no public Swift sources are found, disable the rule to avoid adding empty jobs.
- if not enabled then - return - end + if not enabled then + target:rule_enable("swift.interop", false) + return + endBased on past review comments.
xmake/toolchains/xcode/load_macosx.lua (4)
48-50: Unconditional “-lz” may be unnecessary and surprising.Forcing zlib linkage globally can cause unwanted deps or link failures on targets that don’t use zlib.
Drop “-lz” here and let targets opt-in:
- toolchain:add('ldflags', '-arch', arch, targetflag, '-isysroot', xcode_sysroot, '-lz') - toolchain:add('shflags', '-arch', arch, targetflag, '-isysroot', xcode_sysroot, '-lz') + toolchain:add('ldflags', '-arch', arch, targetflag, '-isysroot', xcode_sysroot) + toolchain:add('shflags', '-arch', arch, targetflag, '-isysroot', xcode_sysroot)
55-55: Don’t enable ARC globally by default.Forcing
-fobjc-arccan break projects that intentionally use MRC or mixed code. Prefer making this opt-in via project config.- toolchain:add('mxflags', '-fobjc-arc') + -- Let projects opt-in: add_mxflags("-fobjc-arc") in xmake.lua if desired
28-31: Avoid bare assert for simulator; raise a helpful error or ignore.
assert(not simulator)aborts without context. If this loader is selected incorrectly, guide the user.- assert(not simulator) + if simulator then + raise("macosx toolchain cannot target the simulator; use the iPhone/tvOS/watchOS simulator toolchain instead") + end
24-24:xcode_sdkveris read but unused.Either use it to default
target_minver(when not set) or remove the variable.- local xcode_sdkver = toolchain:config('xcode_sdkver') or get_config("xcode_sdkver") + -- local xcode_sdkver = toolchain:config('xcode_sdkver') or get_config("xcode_sdkver")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (30)
tests/projects/swift/bidirectional_cxx_interop_lib/include/fibonacci/fibonacci.h(1 hunks)tests/projects/swift/bidirectional_cxx_interop_lib/include/fibonacci/module.modulemap(1 hunks)tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.cpp(1 hunks)tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.swift(1 hunks)tests/projects/swift/bidirectional_cxx_interop_lib/src/fibonacci.cpp(1 hunks)tests/projects/swift/bidirectional_cxx_interop_lib/src/fibonacci.swift(1 hunks)tests/projects/swift/bidirectional_cxx_interop_lib/test.lua(1 hunks)tests/projects/swift/bidirectional_cxx_interop_lib/xmake.lua(1 hunks)tests/projects/swift/cxx_interop/lib/fibonacci/fibonacci.swift(1 hunks)tests/projects/swift/cxx_interop/src/fibonacci.cpp(1 hunks)tests/projects/swift/cxx_interop/test.lua(1 hunks)tests/projects/swift/cxx_interop/xmake.lua(1 hunks)tests/projects/swift/cxx_interop_lib/lib/fibonacci/fibonacci.swift(1 hunks)tests/projects/swift/cxx_interop_lib/src/fibonacci.cpp(1 hunks)tests/projects/swift/cxx_interop_lib/test.lua(1 hunks)tests/projects/swift/cxx_interop_lib/xmake.lua(1 hunks)xmake/core/tool/compiler.lua(1 hunks)xmake/core/tool/toolchain.lua(1 hunks)xmake/languages/swift/xmake.lua(2 hunks)xmake/modules/core/tools/swiftc/has_flags.lua(1 hunks)xmake/rules/swift/xmake.lua(2 hunks)xmake/toolchains/llvm/xmake.lua(2 hunks)xmake/toolchains/swift/xmake.lua(1 hunks)xmake/toolchains/xcode/load_appletvos.lua(1 hunks)xmake/toolchains/xcode/load_applexros.lua(1 hunks)xmake/toolchains/xcode/load_iphoneos.lua(1 hunks)xmake/toolchains/xcode/load_macosx.lua(1 hunks)xmake/toolchains/xcode/load_platform.lua(1 hunks)xmake/toolchains/xcode/load_watchos.lua(1 hunks)xmake/toolchains/xcode/xmake.lua(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (13)
tests/projects/swift/cxx_interop_lib/test.lua (1)
xmake/core/base/os.lua (1)
os.host(1138-1140)
tests/projects/swift/bidirectional_cxx_interop_lib/include/fibonacci/fibonacci.h (1)
tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.cpp (2)
fibonacci_cpp(5-9)fibonacci_cpp(5-5)
tests/projects/swift/cxx_interop/test.lua (1)
xmake/core/base/os.lua (1)
os.host(1138-1140)
xmake/toolchains/swift/xmake.lua (1)
xmake/core/base/path.lua (1)
path.join(283-286)
xmake/rules/swift/xmake.lua (5)
xmake/core/base/os.lua (3)
os.iorunv(1049-1074)os.mkdir(664-682)os.rm(566-600)xmake/core/base/path.lua (1)
path.join(283-286)xmake/modules/async/jobgraph.lua (1)
jobgraph:add(71-95)xmake/core/base/table.lua (1)
table.join(93-106)xmake/core/base/option.lua (1)
option.get(336-345)
tests/projects/swift/bidirectional_cxx_interop_lib/src/fibonacci.cpp (1)
tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.swift (1)
fibonacciSwift(1-7)
xmake/toolchains/llvm/xmake.lua (1)
xmake/core/base/path.lua (1)
path.join(283-286)
tests/projects/swift/bidirectional_cxx_interop_lib/test.lua (1)
xmake/core/base/os.lua (1)
os.host(1138-1140)
tests/projects/swift/cxx_interop_lib/src/fibonacci.cpp (2)
tests/projects/swift/cxx_interop/lib/fibonacci/fibonacci.swift (1)
fibonacciSwift(1-7)tests/projects/swift/cxx_interop_lib/lib/fibonacci/fibonacci.swift (1)
fibonacciSwift(1-7)
xmake/toolchains/xcode/load_macosx.lua (1)
xmake/core/base/path.lua (1)
path.join(283-286)
tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.cpp (1)
tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.swift (1)
fibonacciSwift(1-7)
tests/projects/swift/cxx_interop/src/fibonacci.cpp (2)
tests/projects/swift/cxx_interop/lib/fibonacci/fibonacci.swift (1)
fibonacciSwift(1-7)tests/projects/swift/cxx_interop_lib/lib/fibonacci/fibonacci.swift (1)
fibonacciSwift(1-7)
tests/projects/swift/bidirectional_cxx_interop_lib/src/fibonacci.swift (1)
tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.cpp (2)
fibonacci_cpp(5-9)fibonacci_cpp(5-5)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: build (windows-2022, x86)
- GitHub Check: build (windows-2025, x86)
- GitHub Check: build (windows-2025, x64)
- GitHub Check: build (windows-2022, x86)
- GitHub Check: build (windows-2022, x64)
- GitHub Check: build
- GitHub Check: build
🔇 Additional comments (20)
tests/projects/swift/cxx_interop/xmake.lua (1)
1-9: LGTM!The Swift-C++ interop configuration is well-structured. The settings properly enable bidirectional interop by marking Swift files as public, specifying the module name, interop type, header name, and the cxxmain flag to prevent symbol conflicts.
tests/projects/swift/bidirectional_cxx_interop_lib/src/fibonacci.swift (1)
1-3: LGTM!This test code correctly demonstrates Swift calling a C++ function through the interop bridge.
tests/projects/swift/bidirectional_cxx_interop_lib/include/fibonacci/fibonacci.h (1)
1-6: LGTM!The header properly declares the C-compatible interface with include guards and extern "C" linkage for interop.
tests/projects/swift/bidirectional_cxx_interop_lib/include/fibonacci/module.modulemap (1)
1-3: LGTM!The module map correctly declares the Fibonacci module and exports the fibonacci.h header for C++/Swift interop.
tests/projects/swift/bidirectional_cxx_interop_lib/lib/fibonacci.cpp (1)
5-9: Verify interop with corrected Swift base case.Once the base case is corrected in the Swift implementation (fibonacci.swift), ensure this C++ function correctly delegates to the updated Swift logic for consistent results across the bidirectional interop.
tests/projects/swift/cxx_interop_lib/xmake.lua (1)
1-12: LGTM!The build configuration correctly establishes Swift-C++ interop with appropriate target dependencies, module naming, and language settings.
tests/projects/swift/bidirectional_cxx_interop_lib/xmake.lua (1)
1-23: LGTM!The bidirectional interop configuration correctly establishes:
- A shared
fibonaccitarget with both Swift and C++ sources- Public Swift compiler flags for modulemap discovery
- Separate binary targets for C++ and Swift consumers
- Appropriate dependency relationships
The setup demonstrates a comprehensive Swift-C++ bidirectional interop workflow.
xmake/core/tool/compiler.lua (1)
366-371: LGTM! Clean delegation to the underlying tool.The new
languageflagsmethod follows the established pattern of delegating to the underlying tool via_tool(). The implementation is straightforward and the documentation is consistent with the existing style in this file.xmake/core/tool/toolchain.lua (1)
445-445: LGTM! Consistent toolkind description addition.The new "scar" (Swift static library archiver) description follows the established pattern and is properly positioned in the descriptions table.
xmake/toolchains/xcode/xmake.lua (1)
54-54: LGTM! Consistent with existing Swift toolset declarations.The new scar toolset correctly points to the Swift compiler (swiftc), mirroring the pattern used for other Swift toolsets (sc, scld, scsh).
xmake/languages/swift/xmake.lua (2)
25-26: LGTM! Appropriate language-specific toolkind separation.Renaming the Swift static library toolkind from "ar" to "scar" appropriately distinguishes Swift-specific archiving from C/C++ archiving, allowing for Swift-specific flag handling.
108-108: LGTM! Menu entry consistent with toolkind change.The new menu entry for the Swift Static Library Archiver aligns with the scar toolkind introduced in this file.
xmake/toolchains/xcode/load_applexros.lua (1)
21-25: LGTM! Clean refactoring to centralize platform loading.Delegating to
load_platformconsolidates platform-specific configuration logic and reduces code duplication. This pattern is consistent with similar refactoring in other Xcode platform loaders (iphoneos, appletvos, watchos).xmake/toolchains/swift/xmake.lua (2)
31-32: LGTM! Consistent scar toolset addition.The new scar (Swift static library archiver) toolset follows the pattern of other Swift toolsets and aligns with the broader scar integration across toolchains.
36-47: LGTM! Proper macOS SDK configuration with platform delegation.The conditional macOS logic correctly constructs the Xcode SDK path and delegates to the platform-specific loader, aligning with the refactoring pattern used in other Xcode toolchain loaders.
xmake/toolchains/xcode/load_watchos.lua (1)
21-25: Refactoring correctly addresses scarflags for watchOS.Verification confirms the refactored
load_platformimplementation properly handles scarflags with both-targetand-sdkfor watchOS. In fact, the refactoring fixes a bug in the original code: the previousload_watchos.luaincorrectly used"-target %s-apple-ios%s"(iOS platform triple) instead of watchOS. The new implementation correctly generates"-target arm64-apple-watchos..."by using theplatparameter. The scarflags configuration at line 57 ofload_platform.luaincludes all required elements:-sdk,-target(viatargetflag),-emit-library, and-static.xmake/modules/core/tools/swiftc/has_flags.lua (1)
76-79: Acknowledge valid concern about error suppression logic, but unable to confirm the issue is wrong without swiftc installed.The code at lines 76-79 does invert the normal success/failure semantics: it treats all errors except "unknown argument" as success. Your concern is justified—this broad suppression could mask legitimate compilation failures.
However, I cannot test swiftc directly in the sandbox environment to understand what specific error patterns it produces. The logic appears intentional (committed as a recent fix:
ddcda7d7), but without access to the original PR discussion or swiftc's actual error output, I cannot definitively confirm whether:
- swiftc emits benign errors to stderr even during successful compilation
- The empty test file is expected to fail compilation for reasons unrelated to the flag
- This is an actual bug that went unnoticed
The code is production-ready and
swift_frontend/has_flags.luainherits the same logic, suggesting deliberate design rather than oversight.xmake/toolchains/xcode/load_appletvos.lua (1)
21-25: Delegation looks good.Simple handoff to
load_platform(toolchain, "tvos")keeps behavior centralized. No issues.xmake/toolchains/xcode/load_iphoneos.lua (1)
21-25: LGTM: centralized iOS loader.Consistent with the new shared platform loader; no issues spotted.
xmake/toolchains/xcode/load_macosx.lua (1)
66-90: Catalyst iOSSupport paths: solid guard and path joins. LGTM.If you want extra safety, consider verifying these subpaths exist for the active SDK before adding them (optional).
xmake/rules/swift/xmake.lua
Outdated
| local languages = target:get("languages") | ||
| for _, language in ipairs(languages) do | ||
| if language:startswith("c++") | ||
| or language:startswith("cxx") | ||
| or language:startswith("gnu++") | ||
| or language:startswith("gnuxx") then | ||
| -- c++26 currently prevent compilation of swift modules | ||
| local v = compinst:languageflags(language:gsub("26", "23"):gsub("latest", "23")) | ||
| if v then return v end | ||
| end | ||
| end | ||
| end |
There was a problem hiding this comment.
Nil-guard languages when deriving C++ standard.
target:get("languages") can be nil. Add a quick guard.
- local languages = target:get("languages")
- for _, language in ipairs(languages) do
+ local languages = target:get("languages")
+ if not languages then return end
+ for _, language in ipairs(languages) do📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| local languages = target:get("languages") | |
| for _, language in ipairs(languages) do | |
| if language:startswith("c++") | |
| or language:startswith("cxx") | |
| or language:startswith("gnu++") | |
| or language:startswith("gnuxx") then | |
| -- c++26 currently prevent compilation of swift modules | |
| local v = compinst:languageflags(language:gsub("26", "23"):gsub("latest", "23")) | |
| if v then return v end | |
| end | |
| end | |
| end | |
| local languages = target:get("languages") | |
| if not languages then return end | |
| for _, language in ipairs(languages) do | |
| if language:startswith("c++") | |
| or language:startswith("cxx") | |
| or language:startswith("gnu++") | |
| or language:startswith("gnuxx") then | |
| -- c++26 currently prevent compilation of swift modules | |
| local v = compinst:languageflags(language:gsub("26", "23"):gsub("latest", "23")) | |
| if v then return v end | |
| end | |
| end | |
| end |
🤖 Prompt for AI Agents
In xmake/rules/swift/xmake.lua around lines 84 to 95, target:get("languages")
can be nil which will cause an error when iterating; add a nil-guard immediately
after fetching languages (e.g., if not languages then return end) so the
function exits safely when no languages are defined before the for-loop that
derives the C++ standard.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
xmake/rules/swift/xmake.lua (1)
79-92: Add nil-guard forlanguages.
target:get("languages")can returnnil, causingipairs(nil)on line 82 to raise an error.Apply this diff to guard against nil:
local function _get_target_cppversion() local compinst = target:compiler("cxx") local languages = target:get("languages") + if not languages then return end for _, language in ipairs(languages) do
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
xmake/rules/swift/xmake.lua(2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
xmake/rules/swift/xmake.lua (5)
xmake/core/base/os.lua (3)
os.iorunv(1049-1074)os.mkdir(664-682)os.rm(566-600)xmake/core/base/path.lua (1)
path.join(283-286)xmake/modules/async/jobgraph.lua (1)
jobgraph:add(71-95)xmake/core/base/table.lua (1)
table.join(93-106)xmake/core/base/option.lua (1)
option.get(336-345)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
- GitHub Check: build (windows-2025, x86)
- GitHub Check: build (macos-13, x86_64)
- GitHub Check: build (windows-2025, x86)
- GitHub Check: build (windows-2025, arm64)
- GitHub Check: build (macos-13, x86_64)
- GitHub Check: build (windows-2025, x64)
- GitHub Check: build
- GitHub Check: build
- GitHub Check: build (MINGW32, i686, /mingw32)
- GitHub Check: build (macos-14, arm64)
🔇 Additional comments (2)
xmake/rules/swift/xmake.lua (2)
181-190: LGTM! Interop configuration is correctly applied.The logic properly detects C++ interop mode, adds appropriate flags (
-cxx-interoperability-mode=default,-parse-as-library), and forces the module name. The implementation is sound.
206-221: LGTM! Dependencies correctly declared.The swift rule now properly depends on
swift.interop, runtime utilities, link inheritance, and linker rules. This ensures correct build order and capability integration.
…interop rule is not used
4a764f4 to
716bc9f
Compare
| ) | ||
| end | ||
|
|
||
| local compinst = import("core.tool.compiler").load("sc") |
There was a problem hiding this comment.
why do not use local compinst = target:compiler("sc") and compinst:compflags()?
There was a problem hiding this comment.
because i don't know why but
local compinst = import("core.tool.compiler").load("sc")
local compinst2 = target:compiler("sc")
print(compinst:program())
print(compinst2:program())give me
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend
/usr/local/Cellar/llvm/21.1.4/bin/clang++
xmake/rules/swift/xmake.lua
Outdated
| -- c++26 currently prevent compilation of swift modules | ||
| local v = compinst:languageflags(language:gsub("26", "23"):gsub("latest", "23")) | ||
| if v then return v end | ||
| import("core.cache.localcache") |
this PR introduces the swift.interop rule (automatically enabled when
swift.interopis set)and these target values
Summary by CodeRabbit
New Features
Tests