SwiftCompilerSources doesn't work on Windows ARM64

hjyamauchi commented 4 months ago

Description

The compiler binary from the Windows ARM64 toolchain build crashes (segfaults) right after it's launched and it cannot even compile a hello world program.

https://download.swift.org/development/windows10-arm64/swift-DEVELOPMENT-SNAPSHOT-2024-06-03-a/swift-DEVELOPMENT-SNAPSHOT-2024-06-03-a-windows10-arm64.exe https://ci-external.swift.org/job/swift-main-windows-toolchain-arm64/

Reproduction

Compile the hello world swift program

Stack dump

swiftc hello.swift -o hello
error: compile command failed due to exception 5 (use -v to see invocation)
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0.      Program arguments: C:/Users/hiroshi/AppData/Local/Programs/Swift/Toolchains/0.0.0+Asserts/usr/bin/swift-frontend.exe -frontend -c -primary-file C:\\Users\\hiroshi\\hello.swift -target aarch64-unknown-windows-msvc -Xllvm -aarch64-use-tbi -disable-objc-interop -sdk C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Platforms\\0.0.0\\Windows.platform\\Developer\\SDKs\\Windows.sdk -color-diagnostics -empty-abi-descriptor -Xcc -working-directory -Xcc C:\\Users\\hiroshi -resource-dir C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\swift -module-name hello -plugin-path C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin -plugin-path C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\local\\bin -o C:\\Users\\hiroshi\\AppData\\Local\\Temp\\TemporaryDirectory.M79sPs\\hello-1.o
1.      Swift version 6.0-dev (LLVM 6a4cb0f4db7bec7, Swift 76d5dd44894ccb0)
2.      Compiling with effective version 5.10
3.      While evaluating request ExecuteSILPipelineRequest(Run pipelines { SILGen Passes } on SIL for hello)
4.      While running pass #1 SILFunctionTransform "LifetimeDependenceInsertion" on SILFunction "@main".
Exception Code: 0xC0000005
 #0 0x00007ff734b3c154 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x13fc154)
 #1 0x00007ff7338bac08 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x17ac08)
 #2 0x00007ff73377b018 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3b018)
 #3 0x00007ff733757b78 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x17b78)
 #4 0x00007ff73432a5e8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbea5e8)
 #5 0x00007ff734347e0c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc07e0c)
 #6 0x00007ff734346d20 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc06d20)
 #7 0x00007ff734340310 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc00310)
 #8 0x00007ff734340670 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc00670)
 #9 0x00007ff73433ffec (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbfffec)
#10 0x00007ff7343937a8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc537a8)
#11 0x00007ff734337b14 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbf7b14)
#12 0x00007ff7343406f4 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc006f4)
#13 0x00007ff73432a664 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbea664)
#14 0x00007ff733d87370 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x647370)
#15 0x00007ff733b1d9d4 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd9d4)
#16 0x00007ff733b1e5a0 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3de5a0)
#17 0x00007ff733b1394c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3d394c)
#18 0x00007ff733b24df8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3e4df8)
#19 0x00007ff733b1d414 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd414)
#20 0x00007ff733b1d690 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd690)
#21 0x00007ff733b1f540 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3df540)
#22 0x00007ff733aaf364 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x36f364)
#23 0x00007ff733aaeef8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x36eef8)
#24 0x00007ff7399aac08 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x626ac08)
#25 0x00007ff7399aaca4 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x626aca4)
#26 0x00007ff84ce12310 (C:\Windows\System32\KERNEL32.DLL+0x12310)
#27 0x00007ff84f395b2c (C:\Windows\SYSTEM32\ntdll.dll+0x75b2c)

Expected behavior

No crash

Environment

Windows ARM64

Additional information

No response

hjyamauchi commented 4 months ago

https://github.com/swiftlang/swift/pull/74599 seems to change the error to the following locally for me. So it may be fixing an error but the compiler still crashes.

swiftc hello.swift -o hello.exe
error: compile command failed due to exception 29 (use -v to see invocation)
Optimizer/Context.swift:42: Fatal error: unhandled SILStage case
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0.      Program arguments: C:/Users/hiroshi/AppData/Local/Programs/Swift/Toolchains/0.0.0+Asserts/usr/bin/swift-frontend.exe -frontend -c -primary-file C:\\Users\\hiroshi\\hello.swift -target aarch64-unknown-windows-msvc -Xllvm -aarch64-use-tbi -disable-objc-interop -sdk C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Platforms\\0.0.0\\Windows.platform\\Developer\\SDKs\\Windows.sdk -color-diagnostics -empty-abi-descriptor -Xcc -working-directory -Xcc C:\\Users\\hiroshi -resource-dir C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\swift -module-name hello -plugin-path C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin -plugin-path C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\local\\bin -o C:\\Users\\hiroshi\\AppData\\Local\\Temp\\TemporaryDirectory.Ad0YYo\\hello-1.o
1.      Swift version 6.0-dev (LLVM 6a4cb0f4db7bec7, Swift 76d5dd44894ccb0)
2.      Compiling with effective version 5.10
3.      While evaluating request ExecuteSILPipelineRequest(Run pipelines { Mandatory Diagnostic Passes + Enabling Optimization Passes } on SIL for hello)
4.      While running pass #10 SILFunctionTransform "LetPropertyLowering" on SILFunction "@main".
Exception Code: 0xC000001D
 #0 0x00007fff7ca256a4 $ss17_assertionFailure__4file4line5flagss5NeverOs12StaticStringV_SSAHSus6UInt32VtF (C:\Users\hiroshi\AppData\Local\Programs\Swift\Runtimes\0.0.0\usr\bin\swiftCore.dll+0x156a4)
 #1 0x00007ff6f9e85744 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x35744)
 #2 0x00007ff6f9e67bd8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x17bd8)
 #3 0x00007ff6faa3a660 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbea660)
 #4 0x00007ff6faa57e84 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc07e84)
 #5 0x00007ff6faa56d98 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc06d98)
 #6 0x00007ff6faa50388 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc00388)
 #7 0x00007ff6faa506e8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc006e8)
 #8 0x00007ff6faa50064 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc00064)
 #9 0x00007ff6faaa3820 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc53820)
#10 0x00007ff6faa47b8c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbf7b8c)
#11 0x00007ff6faa5076c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc0076c)
#12 0x00007ff6faa3a74c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbea74c)
#13 0x00007ff6fa4973f0 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x6473f0)
#14 0x00007ff6fa22da54 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dda54)
#15 0x00007ff6fa22e620 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3de620)
#16 0x00007ff6fa2239cc (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3d39cc)
#17 0x00007ff6fa234e78 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3e4e78)
#18 0x00007ff6fa22d494 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd494)
#19 0x00007ff6fa22d710 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd710)
#20 0x00007ff6fa22f5c0 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3df5c0)
#21 0x00007ff6fa1bf3e4 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x36f3e4)
#22 0x00007ff6fa1bef78 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x36ef78)
#23 0x00007ff7000bac78 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x626ac78)
#24 0x00007ff7000bad14 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x626ad14)
#25 0x00007ff84ce12310 (C:\Windows\System32\KERNEL32.DLL+0x12310)
#26 0x00007ff84f395b2c (C:\Windows\SYSTEM32\ntdll.dll+0x75b2c)

hjyamauchi commented 4 months ago

https://github.com/swiftlang/swift/pull/74432 temporarily fixes this issue.

kavon commented 4 months ago

This was fixed in https://github.com/swiftlang/swift/pull/74599

kavon commented 4 months ago

Oh I see that you mentioned https://github.com/swiftlang/swift/pull/74599 already as not quite fixing it. I think https://github.com/swiftlang/swift/pull/74432 is fine for now until we can address the interop issues with SwiftCompilerSources for this platform.

kavon commented 4 months ago

I'll leave this issue open to keep track of actually making this work.

hjyamauchi commented 4 months ago

@kavon yes. Do you know if anyone working on this issue?

hjyamauchi commented 2 months ago

@eeckstein @kavon I believe I found a codegen bug that was a cause for this issue.

A wrong register (x8) is used for an sret argument in a swift-to-C++ call where C++ rightly expects it to be on x1.

swift_frontend!BridgedFunction::getFirstBlock (C++)

00007ff6`f0514ff0 f353bea9 stp     x19, x20, [sp, #-0x20]!
00007ff6`f0514ff4 fe0b00f9 str     lr, [sp, #0x10]
00007ff6`f0514ff8 0a0040f9 ldr     x10, [x0]
00007ff6`f0514ffc 081780d2 mov     x8, #0xB8
00007ff6`f0515000 f40301aa mov     x20, x1
00007ff6`f0515004 5f0100f1 cmp     x10, #0
00007ff6`f0515008 49a10291 add     x9, x10, #0xA8
00007ff6`f051500c 0901899a cseleq  x9, x8, x9
00007ff6`f0515010 280140f9 ldr     x8, [x9]
00007ff6`f0515014 08f17d92 and     x8, x8, #-8
00007ff6`f0515018 3f0108eb cmp     x9, x8
00007ff6`f051501c 61000054 bne     swift_frontend!BridgedFunction::getFirstBlock+0x38 (7ff6f0515028)
00007ff6`f0515020 130080d2 mov     x19, #0
00007ff6`f0515024 11000014 b       swift_frontend!BridgedFunction::getFirstBlock+0x78 (7ff6f0515068)
00007ff6`f0515028 49c10291 add     x9, x10, #0xB0
00007ff6`f051502c 5f0100f1 cmp     x10, #0
00007ff6`f0515030 081880d2 mov     x8, #0xC0
00007ff6`f0515034 0801899a cseleq  x8, x8, x9
00007ff6`f0515038 130140f9 ldr     x19, [x8]
00007ff6`f051503c 680240f9 ldr     x8, [x19]
00007ff6`f0515040 08250253 ubfx    w8, w8, #2, #8
00007ff6`f0515044 28010036 tbz     w8, #0, swift_frontend!BridgedFunction::getFirstBlock+0x78 (7ff6f0515068)
00007ff6`f0515048 684d03f0 adrp    x8, swift_frontend!`string'+0x10 (7ff6f6ec4000)
00007ff6`f051504c 01810191 add     x1, x8, #0x60 (7ff6f6ec4060 = swift_frontend!`string')
00007ff6`f0515050 684d03f0 adrp    x8, swift_frontend!`string'+0x10 (7ff6f6ec4000)
00007ff6`f0515054 00a10391 add     x0, x8, #0xE8 (7ff6f6ec40e8 = swift_frontend!`string')
00007ff6`f0515058 084d0390 adrp    x8, swift_frontend!__imp_$s20_CompilerSwiftSyntax012IfConfigDeclC0VAA0C8ProtocolAAMc (7ff6f6eb5000)
00007ff6`f051505c 08f542f9 ldr     x8, [x8, swift_frontend!__imp__wassert (x8+5E8h)]
00007ff6`f0515060 42118052 mov     w2, #0x8A
00007ff6`f0515064 00013fd6 blr     x8
00007ff6`f0515068 68420091 add     x8, x19, #0x10
00007ff6`f051506c 7f0200f1 cmp     x19, #0
00007ff6`f0515070 e803889a cseleq  x8, xzr, x8
00007ff6`f0515074 880200f9 str     x8, [x20] --------------> crashes here because x20 (x1 at entry) is NULL
00007ff6`f0515078 e00314aa mov     x0, x20
00007ff6`f051507c fe0b40f9 ldr     lr, [sp, #0x10]
00007ff6`f0515080 f353c2a8 ldp     x19, x20, [sp], #0x20
00007ff6`f0515084 c0035fd6 ret     

swift_frontend!$s3SIL8FunctionC6blocksAA14BasicBlockListVvg (Swift)

00007ff6`eecb3d80 00c300b0 adrp    x0, swift_frontend!BridgedGlobalVar::getDebugDescription+0x18 (7ff6f0514000)
00007ff6`eecb3d84 00c03f91 add     x0, x0, #0xFF0 (7ff6f0514ff0 = swift_frontend!BridgedFunction::getFirstBlock)
00007ff6`eecb3d88 01000014 b       swift_frontend!$s3SIL8FunctionC6blocksAA14BasicBlockListVvg+0xc (7ff6eecb3d8c)
00007ff6`eecb3d8c ff8300d1 sub     sp, sp, #0x20
00007ff6`eecb3d90 fe0b00f9 str     lr, [sp, #0x10]
00007ff6`eecb3d94 e90300aa mov     x9, x0
00007ff6`eecb3d98 e0630091 add     x0, sp, #0x18
00007ff6`eecb3d9c e8230091 add     x8, sp, #8 ------------> This should use x1 (correct), not x8 (wrong)
00007ff6`eecb3da0 f40f00f9 str     x20, [sp, #0x18]
00007ff6`eecb3da4 20013fd6 blr     x9 ----------------> calls BridgedFunction::getFirstBlock but it uses x8 (not x1!) as the sret pointer
00007ff6`eecb3da8 e00740f9 ldr     x0, [sp, #8]
00007ff6`eecb3dac 800000b4 cbz     x0, swift_frontend!$s3SIL8FunctionC6blocksAA14BasicBlockListVvg+0x3c (7ff6eecb3dbc)
00007ff6`eecb3db0 081004f0 adrp    x8, swift_frontend!__imp_$ss15ContiguousArrayVMa (7ff6f6eb6000)
00007ff6`eecb3db4 08f144f9 ldr     x8, [x8, swift_frontend!__imp_swift_retain (x8+9E0h)]
00007ff6`eecb3db8 00013fd6 blr     x8
00007ff6`eecb3dbc fe0b40f9 ldr     lr, [sp, #0x10]
00007ff6`eecb3dc0 ff830091 add     sp, sp, #0x20
00007ff6`eecb3dc4 c0035fd6 ret

Draft fix PR: https://github.com/swiftlang/swift/pull/76159

Unfortunately it seems like this is a partial fix as I still get a different type of crash in the OnoneSimplification pass after this the fix but the SwiftCompilerSources-enabled windows/arm64 compiler can now build a hello-world program and the toolchain up to a further point.

Remaining crash

these types are always canonical
UNREACHABLE executed at S:\SourceCache\swift\lib\AST\Type.cpp:1617!
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0.      Program arguments: S:\\b\\5\\bin\\swiftc.exe -frontend -emit-module -filelist C:\\Users\\hiroshi\\AppData\\Local\\Temp\\sources-412e23 -supplementary-output-file-map C:\\Users\\hiroshi\\AppData\\Local\\Temp\\supplementaryOutputs-71a9f9 -disable-objc-attr-requires-foundation-module -target aarch64-unknown-windows-msvc -Xllvm -aarch64-use-tbi -disable-objc-interop -I S:/b/5/./lib/swift/windows -vfsoverlay S:/b/5/tools/swift/stdlib/windows-vfs-overlay.yaml -color-diagnostics -enable-experimental-feature NoncopyableGenerics2 -enable-experimental-feature SuppressedAssociatedTypes -enable-experimental-feature ExtensionImportVisiblity -enable-experimental-feature Macros -enable-experimental-feature FreestandingMacros -enable-experimental-feature Extern -enable-experimental-feature BitwiseCopyable -enable-experimental-feature DebugDescriptionMacro -warn-implicit-overrides -enable-library-evolution -module-cache-path S:/b/5/./module-cache -module-link-name swiftCore -nostdimport -parse-stdlib -resource-dir S:/b/5/./lib/swift -swift-version 5 -tools-directory S:/b/5/bin -O -library-level api -D SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY -D SWIFT_ENABLE_EXPERIMENTAL_DISTRIBUTED -D SWIFT_ENABLE_EXPERIMENTAL_DIFFERENTIABLE_PROGRAMMING -D SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING -D SWIFT_ENABLE_EXPERIMENTAL_OBSERVATION -D SWIFT_ENABLE_SYNCHRONIZATION -D SWIFT_ENABLE_VOLATILE -D SWIFT_RUNTIME_OS_VERSIONING -D SWIFT_STDLIB_ENABLE_UNICODE_DATA -D SWIFT_STDLIB_ENABLE_VECTOR_TYPES -D SWIFT_STDLIB_HAS_COMMANDLINE -D SWIFT_STDLIB_HAS_STDIN -D SWIFT_STDLIB_HAS_ENVIRON -D SWIFT_CONCURRENCY_USES_DISPATCH -D SWIFT_STDLIB_OVERRIDABLE_RETAIN_RELEASE -D SWIFT_THREADING_WIN32 -D SWIFT_ENABLE_REFLECTION -D _WINDLL -D swiftCore_EXPORTS -require-explicit-availability=ignore -enforce-exclusivity=unchecked -group-info-path S:/SourceCache/swift/stdlib/public/core/GroupInfo.json -empty-abi-descriptor -disable-autolinking-runtime-compatibility-concurrency -disable-objc-interop -enable-experimental-concise-pound-file -enable-ossa-modules -enable-lexical-lifetimes=false -disable-implicit-concurrency-module-import -disable-implicit-string-processing-module-import -define-availability "SwiftStdlib 9999:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999" -define-availability "SwiftStdlib 5.0:macOS 10.14.4, iOS 12.2, watchOS 5.2, tvOS 12.2" -define-availability "SwiftStdlib 5.1:macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0" -define-availability "SwiftStdlib 5.2:macOS 10.15.4, iOS 13.4, watchOS 6.2, tvOS 13.4" -define-availability "SwiftStdlib 5.3:macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0" -define-availability "SwiftStdlib 5.4:macOS 11.3, iOS 14.5, watchOS 7.4, tvOS 14.5" -define-availability "SwiftStdlib 5.5:macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0" -define-availability "SwiftStdlib 5.6:macOS 12.3, iOS 15.4, watchOS 8.5, tvOS 15.4" -define-availability "SwiftStdlib 5.7:macOS 13.0, iOS 16.0, watchOS 9.0, tvOS 16.0" -define-availability "SwiftStdlib 5.8:macOS 13.3, iOS 16.4, watchOS 9.4, tvOS 16.4" -define-availability "SwiftStdlib 5.9:macOS 14.0, iOS 17.0, watchOS 10.0, tvOS 17.0" -define-availability "SwiftStdlib 5.10:macOS 14.4, iOS 17.4, watchOS 10.4, tvOS 17.4, visionOS 1.1" -define-availability "SwiftStdlib 6.0:macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0" -define-availability "SwiftStdlib 6.1:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, visionOS 9999" -target-min-inlining-version min -plugin-path S:/b/5/./bin/../lib/swift/host/plugins -in-process-plugin-server-path S:\\b\\5\\bin\\SwiftInProcPluginServer.dll -plugin-path S:\\b\\5\\bin -Xllvm -sil-inline-generics -Xllvm -sil-partial-specialization -Xcc -DSWIFT_STDLIB_HAS_ENVIRON -Xcc -DswiftCore_EXPORTS -Xcc -Xclang -Xcc -fbuiltin-headers-in-system-modules -autolink-library oldnames -autolink-library msvcrt -Xcc -D_MT -Xcc -D_DLL -parse-as-library -module-name Swift -o S:/b/5/./lib/swift/windows/Swift.swiftmodule/aarch64-unknown-windows-msvc.swiftmodule -runtime-compatibility-version none -disable-autolinking-runtime-compatibility-dynamic-replacements
1.      Swift version 6.0-dev (LLVM 44e9ac72b347ffd, Swift cabaa9963ddb177)
2.      Compiling with effective version 5.10
3.      Contents of C:\Users\hiroshi\AppData\Local\Temp\sources-412e23:
4.      While evaluating request ExecuteSILPipelineRequest(Run pipelines { Mandatory Diagnostic Passes + Enabling Optimization Passes } on SIL for Swift)
5.      While running pass #642610 SILFunctionTransform "OnoneSimplification" on SILFunction "@$ss21_fallbackEnumRawValueys5Int64VSgxlF".
 for '_fallbackEnumRawValue(_:)' (at S:/SourceCache/swift/stdlib/public/core/OutputStream.swift:284:10)
Exception Code: 0x80000003
 #0 0x00007ff74635e920 HandleAbort (S:\b\5\bin\swiftc.exe+0x823e920)
 #1 0x00007ffa7ed75f08 (C:\Windows\System32\ucrtbase.dll+0x75f08)
 #2 0x00007ffa7ed76ebc (C:\Windows\System32\ucrtbase.dll+0x76ebc)
 #3 0x00007ff7462b6a8c llvm::llvm_unreachable_internal(char const *, char const *, unsigned int) (S:\b\5\bin\swiftc.exe+0x8196a8c)
 #4 0x00007ff740780b58 swift::TypeBase::computeCanonicalType(void) (S:\b\5\bin\swiftc.exe+0x2660b58)
 #5 0x00007ff73fa8323c BridgedTypeArray::getAt(__int64) const (S:\b\5\bin\swiftc.exe+0x196323c)
 #6 0x00007ff73e23d358 $s3SIL17OptionalTypeArrayVyAA0C0VSgSicig (S:\b\5\bin\swiftc.exe+0x11d358)
 #7 0x00007ff73e12b188 $s3SIL11BuiltinInstC9OptimizerE8simplifyyyAD15SimplifyContextVF (S:\b\5\bin\swiftc.exe+0xb188)
 #8 0x00007ff73e1d8a1c $s9Optimizer17runSimplification2on_17preserveDebugInfo_Sb3SIL8FunctionC_AA0I11PassContextVSbyAE11InstructionC_AA08SimplifyK0VtXEtF019$s9Optimizer23ononecj4AA08i23D0Vvpfiy3SIL0E0C_AA0eD7k11VtcfU_yAE11l2C_pM9G0VtXEfU_Tf1nnnc_n (S:\b\5\bin\swiftc.exe+0xb8a1c)
 #9 0x00007ff73e13788c $s9Optimizer08registerA5TestsyyF (S:\b\5\bin\swiftc.exe+0x1788c)
#10 0x00007ff73efa2de8 UpdateBorrowedFromPass::run(void) (S:\b\5\bin\swiftc.exe+0xe82de8)
#11 0x00007ff73efcef44 swift::SILPassManager::runPassOnFunction(unsigned int, class swift::SILFunction *) (S:\b\5\bin\swiftc.exe+0xeaef44)
#12 0x00007ff73efcdb34 swift::SILPassManager::runFunctionPasses(unsigned int, unsigned int) (S:\b\5\bin\swiftc.exe+0xeadb34)
#13 0x00007ff73efc2a80 swift::SILPassManager::execute(void) (S:\b\5\bin\swiftc.exe+0xea2a80)
#14 0x00007ff73efc2e40 swift::SILPassManager::executePassPipelinePlan(class swift::SILPassPipelinePlan const &) (S:\b\5\bin\swiftc.exe+0xea2e40)
#15 0x00007ff73efc2734 swift::ExecuteSILPipelineRequest::evaluate(class swift::Evaluator &, struct swift::SILPipelineExecutionDescriptor) const (S:\b\5\bin\swiftc.exe+0xea2734)
#16 0x00007ff73f039950 swift::SimpleRequest<class swift::ExecuteSILPipelineRequest, (struct swift::SILPipelineExecutionDescriptor), 1>::evaluateRequest(class swift::ExecuteSILPipelineRequest const &, class swift::Evaluator &) (S:\b\5\bin\swiftc.exe+0xf19950)
#17 0x00007ff73efb3ea4 swift::Evaluator::getResultUncached<class swift::ExecuteSILPipelineRequest, class `class std::tuple<> __cdecl swift::evaluateOrFatal<class swift::ExecuteSILPipelineRequest>(class swift::Evaluator &, class swift::ExecuteSILPipelineRequest)'::`2'::<lambda_1>>(class swift::ExecuteSILPipelineRequest const &, class `class std::tuple<> __cdecl swift::evaluateOrFatal<class swift::ExecuteSILPipelineRequest>(class swift::Evaluator &, class swift::ExecuteSILPipelineRequest)'::`2'::<lambda_1>) (S:\b\5\bin\swiftc.exe+0xe93ea4)
#18 0x00007ff73efc2f14 swift::executePassPipelinePlan(class swift::SILModule *, class swift::SILPassPipelinePlan const &, bool, class swift::irgen::IRGenModule *) (S:\b\5\bin\swiftc.exe+0xea2f14)
#19 0x00007ff73efa2f04 swift::runSILDiagnosticPasses(class swift::SILModule &) (S:\b\5\bin\swiftc.exe+0xe82f04)
#20 0x00007ff73e83d0d8 swift::CompilerInstance::performSILProcessing(class swift::SILModule *) (S:\b\5\bin\swiftc.exe+0x71d0d8)
#21 0x00007ff73e493624 swift::FrontendObserver::parsedArgs(class swift::CompilerInvocation &) (S:\b\5\bin\swiftc.exe+0x373624)
#22 0x00007ff73e493fa0 swift::performCompileStepsPostSema(class swift::CompilerInstance &, int &, class swift::FrontendObserver *) (S:\b\5\bin\swiftc.exe+0x373fa0)
#23 0x00007ff73e48b274 llvm::function_ref<(struct swift::SupplementaryOutputPaths const &)>::callback_fn<class `public: bool __cdecl swift::FrontendInputsAndOutputs::hasTBDPath(void) const'::`2'::<lambda_1>>(__int64, struct swift::SupplementaryOutputPaths const &) (S:\b\5\bin\swiftc.exe+0x36b274)
#24 0x00007ff73e49ae18 llvm::StringRef::trim(class llvm::StringRef) const (S:\b\5\bin\swiftc.exe+0x37ae18)
#25 0x00007ff73e492e18 swift::FrontendObserver::parsedArgs(class swift::CompilerInvocation &) (S:\b\5\bin\swiftc.exe+0x372e18)
#26 0x00007ff73e49323c swift::FrontendObserver::parsedArgs(class swift::CompilerInvocation &) (S:\b\5\bin\swiftc.exe+0x37323c)
#27 0x00007ff73e4951f0 swift::performFrontend(class llvm::ArrayRef<char const *>, char const *, void *, class swift::FrontendObserver *) (S:\b\5\bin\swiftc.exe+0x3751f0)
#28 0x00007ff73e40a988 std::_System_error_category::name(void) const (S:\b\5\bin\swiftc.exe+0x2ea988)
#29 0x00007ff73e40a36c swift::mainEntry(int, char const **) (S:\b\5\bin\swiftc.exe+0x2ea36c)
#30 0x00007ff7463d87f0 invoke_main D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78:0
#31 0x00007ff7463d87f0 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288:0
#32 0x00007ff7463d8ad4 mainCRTStartup D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp:16:0
#33 0x00007ffa82c62310 (C:\Windows\System32\KERNEL32.DLL+0x12310)
#34 0x00007ffa836f5b2c (C:\Windows\SYSTEM32\ntdll.dll+0x75b2c)
<unknown>:0: error: compile command failed due to signal -2147483645 (use -v to see invocation)
Batch file failed at line 6 with errorcode -1

eeckstein commented 2 months ago

Awesome! Thanks a lot!

hjyamauchi commented 2 months ago

CC @compnerd

kavon commented 2 months ago

cc @atrick

eeckstein commented 2 months ago

@hjyamauchi Did you have a chance to look into the other issue, too?

hjyamauchi commented 2 months ago

@eeckstein I'm looking into it. I think I found another indirect result calling convention mismatch but haven't fully figured it out.

hjyamauchi commented 2 months ago

This fixes an additional missing inreg on sret: https://github.com/swiftlang/swift/pull/76324 that was missing from https://github.com/swiftlang/swift/pull/76159 CC @rjmccall @compnerd @hyp

hjyamauchi commented 2 months ago

CC @eeckstein @kavon @egorzhdan @rjmccall @hyp @compnerd

I think I figured out the next (OnoneSimplification) crash referred to above:

The crash happens because of how a struct value type is returned mismatches:

(extension in Optimizer):SIL.BuiltinInst.simplify(Optimizer.SimplifyContext) -> () (Swift)

    swift_frontend!$s3SIL11BuiltinInstC9OptimizerE8simplifyyyAD15SimplifyContextVF:
00007ff6`4a4ab034 ff0307d1 sub     sp, sp, #0x1C0
...
00007ff6`4a4ab16c e9450494 bl      swift_frontend!$s3SIL15SubstitutionMapV16replacementTypesAA17OptionalTypeArrayVvg (7ff64a5bc910) --------> calling SIL.SubstitutionMap.replacementTypes.getter : SIL.OptionalTypeArray (below)
00007ff6`4a4ab170 e20300aa mov     x2, x0 --------------------------------------------------------------------------------------------------> Expecting OptionalTypeArray directly returned in x0 and x1
00007ff6`4a4ab174 e30301aa mov     x3, x1
00007ff6`4a4ab178 e0031faa mov     x0, xzr
00007ff6`4a4ab17c e10302aa mov     x1, x2
00007ff6`4a4ab180 e20303aa mov     x2, x3
00007ff6`4a4ab184 6c480494 bl      swift_frontend!$s3SIL17OptionalTypeArrayVyAA0C0VSgSicig (7ff64a5bd334)
...

SIL.SubstitutionMap.replacementTypes.getter : SIL.OptionalTypeArray (Swift)

    swift_frontend!$s3SIL15SubstitutionMapV16replacementTypesAA17OptionalTypeArrayVvg: 
00007ff6`4a5bc910 041a6114 b       swift_frontend!BridgedTypeArray::fromReplacementTypes (7ff64be03120)  -----> calls fromReplacementTypes below

fromReplacementTypes (C++)

    swift_frontend!BridgedTypeArray::fromReplacementTypes:
00007ff6`4be03120 ff4300d1 sub     sp, sp, #0x10
00007ff6`4be03124 f37b00a9 stp     x19, lr, [sp]
00007ff6`4be03128 ff8300d1 sub     sp, sp, #0x20
00007ff6`4be0312c f30300aa mov     x19, x0
00007ff6`4be03130 e10300f9 str     x1, [sp]
00007ff6`4be03134 e1230091 add     x1, sp, #8
00007ff6`4be03138 e0030091 mov     x0, sp
00007ff6`4be0313c d3443794 bl      swift_frontend!swift::SubstitutionMap::getReplacementTypes (7ff64cbd4488)
00007ff6`4be03140 1000c03d ldr     q16, [x0]
00007ff6`4be03144 e00313aa mov     x0, x19
00007ff6`4be03148 083e184e umov    x8, v16.d[1]
00007ff6`4be0314c 700200fd str     d16, [x19] -------------> returning OptionalTypeArray indirectly via x0, a mismatch!
00007ff6`4be03150 680600f9 str     x8, [x19, #8] ----------> returning OptionalTypeArray indirectly via x0, a mismatch!
00007ff6`4be03154 ff830091 add     sp, sp, #0x20
00007ff6`4be03158 f37b40a9 ldp     x19, lr, [sp]
00007ff6`4be0315c ff430091 add     sp, sp, #0x10
00007ff6`4be03160 c0035fd6 ret

Apparently, on Windows ARM64, how a struct value type is returned is (more) sensitive to the conditions including whether a user-defined constructor exists, etc. See this doc.

That caused a calling convention mismatch between the non-USED_IN_CPP_SOURCE (Swift) side and the USE_IN_CPP_SOURCE (C++) side and resulted in a crash.

It seems like the original intent is to control the visibility of some C++ types but it also had an unintended consequence on how the struct type is returned on Windows ARM64!

The draft fix PR is here, pending the CI results. The included test demonstrates the issue and the fix.

After this fix (along with https://github.com/swiftlang/swift/pull/76324) the SwiftCompilerSources-enabled windows/arm64 compiler can now build a hello-world program with -O and the toolchain up to a further point.

Yet, this fix didn't seem to have fully fixed the SwiftCompilerSources-enabled windows/arm64 compiler yet.

But I will check whether this issue exists in the other bridging struct types and if so, whether fix those will fully fix it or not.

eeckstein commented 2 months ago

Thanks, great progress!

hjyamauchi commented 2 months ago

TODO: once we resolve this issue, we need to cherrypick the fixes to release/6.0.

hjyamauchi commented 2 months ago

If I add constructors to the other bridged C++ types so their value types are indirectly returned, the SwiftCompilerSource-enabled ARM64 compiler seems to be able to successfully build the toolchain in my local setup. This needs more testing and validation as I'd need to test at head and figure out how to revive the self-hosting build, but this is a good sign!

Here's a draft PR: https://github.com/swiftlang/swift/pull/76589 which is a follow-up to the previous https://github.com/swiftlang/swift/pull/76433

CC @eeckstein @kavon @egorzhdan @rjmccall @hyp @compnerd @DougGregor

hjyamauchi commented 2 months ago

https://github.com/swiftlang/swift/pull/76589 has been merged.

eeckstein commented 2 months ago

@hjyamauchi Nice work! Can we now enable SwiftCompilerSources on Windows arm64, or are there still some issues?

hjyamauchi commented 2 months ago

@eeckstein This PR needs to be merged before enabling SwiftCompilerSources on Windows arm64: https://github.com/swiftlang/swift/pull/76324

hjyamauchi commented 1 month ago

A plan to get the Windows ARM64 compiler working again:

With https://github.com/swiftlang/swift/pull/76324 included, I can locally confirm that the Windows ARM64 compiler is a working state as far as I can tell.

There were the two categories of the fixes so far, (a) adding missing inreg to sret in IRGen and (b) adding constructors to bridged C++ types to match the struct return calling convention between Swift/C++ in the SwiftCompilerSources code.

Noting (a) is in the codegen and we need that fix on the bootstrap/pinned toolchain side, as opposed to the currently-being-built toolchain side, we need to have the fix in and update the bootstrap/pinned toolchain. That is, simply a new build with all the fixes isn't sufficient to fix the issue, but rather we need a two-step fix: have all the fixes in, built a new toolchain and then use that to bootstrap another toolchain build.

I did a one-cycle of self-hosting cross-compiling build on main (do a win/x64 toolchain build after the fixes, use the just-built win/x64 toolchain as the bootstrap/pinned toolchain for a win/arm64-on-win/x64 cross-compile build) and the final win/arm64 appears to be good to the extent I locally tested. It can work as a bootstrap/pinned toolchain for a native win/arm64 build and can build the arm64 version of our internal app in arm64 to the same extent as the X64 version (currently hits a known build failure).

@compnerd suggested backporting the fixes to the 5.10 release and use it as a new bootstrap toolchain for main. So I will try and see if this works.

The rough steps:

Merge https://github.com/swiftlang/swift/pull/76324 in main
Backport the fixes to release/5.10, create a new 5.10 build
Enable SwiftCompilerSources in main
Check if that can bootstrap a new main build (if not, debug further)
Update the bootstrap toolchain used for the main CI with the above new 5.10 build
Do a new build in the main CI
Done

(and doing similar steps for release/6)

The review for https://github.com/swiftlang/swift/pull/76324 seems to be not fast-progressing, I'd appreciate anyone's help there.

CC @eeckstein @egorzhdan @compnerd @rjmccall @hyp @DougGregor

eeckstein commented 1 month ago

Sounds good! Thanks a lot for doing all this work! @shahmishal is there any problem back-porting the fixes to the Windows 5.10 compiler?

hjyamauchi commented 1 month ago

An update:

Both the inline bridging mode and cherrypicking the fixes to 5.10 and using it to bootstrap main at head locally worked fine.

So it seems like if we can get the PR in one way or another, I think that the rest should go smoothly.

CC @eeckstein @egorzhdan @compnerd @rjmccall @hyp @DougGregor

hjyamauchi commented 3 weeks ago

Finally merged the PR. Now that the necessary PRs have been merged, I'll move onto cherrypicking the PRs to release/5.10 and release/6.0:

5.10: https://github.com/swiftlang/llvm-project/pull/7533 https://github.com/swiftlang/swift/pull/76159 https://github.com/swiftlang/swift/pull/76324 https://github.com/llvm/llvm-project/pull/111597 (As SwiftCompilerSources isn't enabled in 5.10, we don't need the Bridged type ABI fixes like https://github.com/swiftlang/swift/pull/76433)

6.0: https://github.com/swiftlang/swift/pull/76433 https://github.com/swiftlang/swift/pull/76589 https://github.com/swiftlang/swift/pull/76159 https://github.com/swiftlang/swift/pull/76324 https://github.com/llvm/llvm-project/pull/111597

CC @eeckstein @compnerd

hjyamauchi commented 3 weeks ago

Created cherrypick PRs for release/6.0:

hjyamauchi commented 3 weeks ago

Created cherrypick PRs for release/5.10:

However,

I'm hitting some swift test failures that did not occur with release/6.0 or main. Details are here
The 5.10 CI on https://github.com/swiftlang/swift/pull/77277 doesn't seem to accept the @swift-ci command to test with https://github.com/swiftlang/llvm-project/pull/9478

rjmccall commented 3 weeks ago

Can you explain the motivation for cherry-picking all the way back to 5.10? 6.0 is released, and we don't generally put effort into pulling fixes back to older releases. We would for some kind of serious security flaw, but that doesn't seem like it applies.

eeckstein commented 3 weeks ago

We are using 5.10 as host tools when building SwiftCompilerSources. In order to enable SwiftCompilerSources in the Windows arm64 compiler (the only platform where it's not enabled, yet), we need to cherry-pick the fixes to 5.10.

hjyamauchi commented 2 weeks ago

I'm afraid that the fixing missing inreg-on-sret issue is critical to fix the win/arm64 codegen/IRGen part of the compiler on the base/pinned/bootstrap/host-tools side of the toolchain because that's what compiles the Swift compiler (noting that the Swift compiler is written in Swift and the base Swift compiler needs to be able to do correct win/arm64 codegen for the newly-built Swift compiler to work correctly). (I'd be happy to be wrong about this as that'd be easier and I wouldn't need to fix the failing tests in 5.10 :)

Alternatively we may be able to use a new 6.0 build as the new base toolchain for 6.0/main. My understanding on what it'd mean is here: https://github.com/swiftlang/swift/pull/77277#issuecomment-2452360345

rjmccall commented 2 weeks ago

The problem we're looking at in the PR is that it seems like 5.10 is, unsurprisingly, missing about 6 months of bug fixes to C++ interop. Maybe that ends up being a relatively small number of patches, but if just rebasing onto 6.0 is a viable path (and presumably we'll be doing that anyway in the near future?), that might be a more reasonable approach than chasing those patches down.

hjyamauchi commented 2 weeks ago

The problem we're looking at in the PR is that it seems like 5.10 is, unsurprisingly, missing about 6 months of bug fixes to C++ interop. Maybe that ends up being a relatively small number of patches, but if just rebasing onto 6.0 is a viable path (and presumably we'll be doing that anyway in the near future?), that might be a more reasonable approach than chasing those patches down.

Yeah, I'd be inclined to agree with avoiding cherrypicking a potentially many patches.

@compnerd Do you think it's viable to switch the 6.0 and the main branches to a 6.0 pinned/bootstrap toolchain?

I also tested with cherrypicking only the arrangeCXXMethodCall part without the isSRetAfterThis refactoring part (from https://github.com/swiftlang/swift/pull/76324) and all the tests passed (no test failures). (link)

@rjmccall You aren't in favor of this idea, correct?

compnerd commented 2 weeks ago

No, it isn't viable to migrate to 6.0. This is needed to enable the bootstrapping of the 6.0 toolchain, which is built with the 5.10 toolchain. The officially adopted policy is to support 2 versions back, so it would be swift-next-next when we can bump to 6.0.

rjmccall commented 2 weeks ago

To be clear, we're talking here about cherry-picking unknown amounts of work onto old release branches. The result of that is not a "version" because it's not an officially-released toolchain unless we actually roll a 5.10.2 with these patches in it. If we want to live with the two-versions-back constraint, we need to limit ourselves to using features that are actually implemented correctly across all platforms in Swift 5.10.

hjyamauchi commented 2 weeks ago

I'd be wary about the risk and uncertainty of what this cherrypicking entails. I can already locally unbreak this bootstrap issue :) I wonder if we are open to a workaround (for example: dropping the isSRetAfterThis refactoring change.)

compnerd commented 2 weeks ago

If we want to live with the two-versions-back constraint, we need to limit ourselves to using features that are actually implemented correctly across all platforms in Swift 5.10.

I agree; this is something that @DougGregor also mentioned in the original proposal for the policy.

The only other option would be to change the implementation of SwiftCompilerSources to not use this functionality - @eeckstein, is that something that you could look into?

eeckstein commented 2 weeks ago

The only other option would be to change the implementation of SwiftCompilerSources to not use this functionality

Which functionality?

eeckstein commented 2 weeks ago

I wonder if we are open to a workaround (for example: dropping the isSRetAfterThis refactoring change.)

This sounds like the best approach to me, too. Can we just cherry pick the minimal required fix to make SwiftCompilerSources work?

rjmccall commented 2 weeks ago

Again, I don't understand the goal of cherry-picking things to old release branches. The policy as I understand it is that we write code that works with old releases. If we're requiring an updated toolchain, we might as well require 6.0.

Which functionality?

In this case, member functions with struct returns. Possibly only non-trivial struct returns? It's not clear the extent of what doesn't work on Windows on Swift 5.10.

eeckstein commented 2 weeks ago

In this case, member functions with struct returns.

It's clearly not possible to rewrite all code in SwiftCompilerSources to avoid struct returns.

The policy as I understand it is that we write code that works with old releases. If we're requiring an updated toolchain, we might as well require 6.0.

I think this is an exceptional case. There is no problem in making a Windows 5.10 point release with an (isolated) fix.

hjyamauchi commented 1 week ago

I managed to figure out a set of additional PRs to get the failing tests fixed in https://github.com/swiftlang/swift/pull/77277. It's ready for review. @rjmccall @eeckstein @compnerd

The PRs for release/6.0 have been approved and ready to merge.

swiftlang / swift