[windows] Temporarily guard lifetime dependence diagnostics #74599
Conversation
by -enable-experimental-feature NonescapableTypes on the Windows platform These passes do nothing unless the above feature flag is enabled, so the only reason to run the pass is to exercise SwiftCompilerSources and catch invalid SIL. These passes rely on fundamental SwiftCompilerSources abstractions which have not yet been tested outside of the passes. They don't yet handle all SIL patterns, and SIL continues to evolve. We would like to can these issues quickly as we hit them, but only if we have a way of reproducing the failure. Currently, we don't have a way of reproducing Windows-arm64 failures. Workaround for: rdar://128434000 ([nonescapable] [LifetimeDependenceInsertion] Package resolution fails with arm64 Windows toolchain)
|
@swift-ci test |
| @@ -29,6 +29,11 @@ private func log(prefix: Bool = true, _ message: @autoclosure () -> String) { | |||
| let lifetimeDependenceDiagnosticsPass = FunctionPass( | |||
| name: "lifetime-dependence-diagnostics") | |||
| { (function: Function, context: FunctionPassContext) in | |||
| #if os(Windows) | |||
There was a problem hiding this comment.
Can we consider limiting this to os(Windows) && arch(arm64) and same throughout? Is there any thing that would be useful that we could gather to help isolate this issue?
There was a problem hiding this comment.
Can we consider limiting this to
os(Windows) && arch(arm64)and same throughout?
Not much point. These passes literally do nothing at the moment. They just process the SIL using a few SwiftCompilerSources helpers and crash if the SIL is invalid according to those helpers.
Is there any thing that would be useful that we could gather to help isolate this issue?
For the crashing function, identifying the difference in -emit-silgen between x86 and arm64 would be a good start. --Note that the pretty stack trace should print the name of the function being compiled.--
I can't imagine why there's any difference in SIL.
A symbolicated stack trace might be nice.
In general, I don't want to get any compiler crashers for projects that haven't tried to build with an asserts compiler.
But since I won't be able to look at it for a week, there's no reason to hold up any toolchain builds.
There was a problem hiding this comment.
Okay, sounds like the value of the additional SIL validation is low?
|
@swift-ci smoke test |
by -enable-experimental-feature NonescapableTypes
on the Windows platform
These passes do nothing unless the above feature flag is enabled, so the only reason to run the pass is to exercise SwiftCompilerSources and catch invalid SIL.
These passes rely on fundamental SwiftCompilerSources abstractions which have not yet been tested outside of the passes. They don't yet handle all SIL patterns, and SIL continues to evolve. We would like to can these issues quickly as we hit them, but only if we have a way of reproducing the failure. Currently, we don't have a way of reproducing Windows-arm64 failures.
Workaround for:
rdar://128434000 ([nonescapable] [LifetimeDependenceInsertion] Package resolution fails with arm64 Windows toolchain)