Open dreampiggy opened 1 year ago
IamYJLee
commented
11 months ago @dreampiggy When I build the code that's been tagged for the Swift 5.9 release and subsequently run the Swift compatibility test, I encounter the same error. Do you have any ongoing activities?
dreampiggy
commented
11 months ago I modify the Swift compiler source code and write the PlatformKind::visionOS for enum case 13, PlatformKind::visionSimulator for enum case 14, and compile the internal project successfully.
IamYJLee
commented
11 months ago I modify the Swift compiler source code and write the
PlatformKind::visionOSfor enum case 13,PlatformKind::visionSimulatorfor enum case 14, and compile the internal project successfully.
@dreampiggy
I added PlatformKind::visionOS, PlatformKind::visionSimulator and handled it with the same process as the PlatformKind::none case. What do you think?
Errors like #67857 and #68034 no longer occur.
dreampiggy
commented
11 months ago @IamYJLee
Another quick fix is to avoid the availability attr and availability expr, just fix the issue when compile for target (like iOS) with swiftmodule which contains visionOS in the AST.
@avaiable (iOS 10, visionOS 1, *)
class Foobar {}=>
@avaiable (iOS 10, *)
class Foobar {}if #available(iOS 10, visionOS 1, *) {}=>
if #available(iOS 10, *) {}@IamYJLee Another quick fix is to avoid the
availability attrandavailability expr, just fix the issue when compile for target (like iOS) with swiftmodule which contains visionOS in the AST.
- Available Atrribute
@avaiable (iOS 10, visionOS 1, *) class Foobar {}=>
@avaiable (iOS 10, *) class Foobar {}
- Available Expression (Swift inline function which embed AST of exprs)
if #available(iOS 10, visionOS 1, *) {}=>
if #available(iOS 10, *) {}
Thank you so much.
I added PlatformKind::visionOS, PlatformKind::visionSimulator and handled it with the same process as the > PlatformKind::none
There is no problem in an arm64 host environment, but in an x86_64 host environment, another crash occurs in the swift compatibility test, so it is not the correct solution.
dreampiggy
commented
10 months ago @IamYJLee Any better idea about the fix before Apple release the full xros target support ? Which should be a big work beyond our effort.
We just use the open-source compiler on the AST consuming and static analysis domain. So this hack is suitable for us.
dreampiggy
commented
8 months ago Since the LLVM part is merged-in. I think we can re-call this issue.
https://github.com/llvm/llvm-project/pull/77707 https://github.com/llvm/llvm-project/pull/78373 https://github.com/llvm/llvm-project/pull/78392
Motivation
Current Swift compiler on
release/5.9.0branch, does not contains any xrOS(Apple VisionOS) support code. However, in Swift compiler itself, it contains the support code for each platform for this syntax:And it will encode the
swift::PlatformKindinto the serialized AST (.swiftmodule file)Which means, if the open-source Swift compiler does not contains the support, when loading an Apple's provided swiftmodule (like libswiftFoundation.swiftmodule), will hit the assertion, even if we don't compile for that xrOS platform.
See: https://github.com/apple/swift/blob/d4ee7bffa1f9ff67b5ca717683a316f3a7acb425/lib/AST/PlatformKind.cpp#L104
Compiler assertion here:
Solution
Provide the
PlatformKind::xrOSsupport in Swift compiler, which at least should be able to TypeCheck or LoadAST from the swiftmodule provided by AppleFor linker (ld-64) support for xsOS, which is not needed because it's not part of open-source Swift toolchain.
Alternatives considered
Should we just treat this assertions as warning instead ? But I think the assertions is the basic ensure of the compiler's behavior before the final distribution to the developers.