"Stored value type does not match pointer operand type!" compiler crash #59572
Labels
assertion failure
Bug → crash: An assertion failure
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
CodeGen
compiler
The Swift compiler in itself
crash
Bug: A crash, i.e., an abnormal termination of software
generics
Feature: generic declarations and types
name shadowing
Feature: name shadowing
patterns
Feature: patterns
swift 5.5
Comments
LeoNatan
added
the
bug
|
This also compiles without crashing the compiler: func setEnumOverrideIfExists<T: RawRepresentable, U>(for key: String, in override: [String: Any], target: inout T) where T.RawValue == U {
if let overrideValue = override[key] as? U, let overrideValue = T(rawValue: overrideValue) {
target = overrideValue
}
} |
LeoNatan
changed the title
|
Could not reproduce with ToT. May I ask that you isolate the following simplification and see whether it crashes in the terminal with func foo<T: RawRepresentable>(src: Any, target: inout T) where T.RawValue == UInt {
if let x = src as? UInt, let x = T(rawValue: x) {
target = x
}
}@xedin do we actually allow this kind of shadowing? |
|
@AnthonyLatsis Reproduced with Xcode 13.2 toolchain: |
|
Hm, doesn't reproduce with the toolchain in Xcode 14.0 b1. I guess we can close the issue. |
Was this the original example or the one I provided? I would like to add a regression test and confirm that the shadowing is supported before we close this for good—we don't want this to suddenly reemerge in a future release. |
|
Not sure what I ran before, but this is with your |
|
Great to know we have a reduced reproducer, thanks! |
|
It might be fixed, the compiler doesn’t crash with the Xcode 14 beta toolchain. |
|
It no longer crashes, but the rebinding of |
|
Well, everywhere else this works as expected. I don’t see why this shadowing wouldn’t be allowed, while shadowing in general is allowed. There is nothing special here. |
|
There are very few occasions where we allow shadowing within the same lexical scope. This could be one of them, except we seem to lack the test coverage. |
|
Thanks! |
|
This is still happening with Xcode 15 beta and Swift 5.9 |
|
@osrufung Please provide a reproducer. I could not get the original example to crash with a recent revision, and I would not expect it to in Xcode 15 beta either since the regression test had already been added by the time the 5.9 branch was cut. |
AnthonyLatsis
added
compiler
|
@AnthonyLatsis I happened to run into what I believe to be this same issue in one of my projects when building with Xcode 15 beta 1, and I managed to narrow it down and create a sample project that reproduces it. Let me know if I should file mine separately, in case it’s not directly related to this one. Here's the reproduction case: import SwiftUI
public enum EnumWithAssociatedValues: Hashable, Codable {
public enum NestedEnum: Int, Codable {
case success
case failure
}
case caseWithoutValues
case caseWithNestedOptionalEnum(NestedEnum?)
/// If this enum case is removed, then the `let result = result` no longer causes a compiler crash.
case caseWithTwoValues(id: String, value: Double)
}
struct ContentView: View {
@State private var enumValue: EnumWithAssociatedValues?
var body: some View {
VStack {
Image(systemName: "globe")
.imageScale(.large)
.foregroundStyle(.tint)
Text("Hello, world!")
}
.padding()
.onChange(of: enumValue) { newValue in
/// Note: the compiler crash occurs even if the call is not made within a SwiftUI view modifier block.
performAction(for: newValue)
}
}
private func performAction(for newValue: EnumWithAssociatedValues?) {
guard let ring = newValue else { return }
/// The line below crashes the Swift compiler in Xcode 15 if using `let result = result` and the enum includes the `caseWithTwoValues` case.
guard case .caseWithNestedOptionalEnum(let result) = ring, let result = result else { return }
switch result {
case .success: print("success")
case .failure: print("failure")
}
}
}Here's the stack dump: Here's an Xcode project with the reproduction case: Swift-59572.zip |
Here you can find a Swift 5.9 Package that reproduce the issue in Xcode 15 |
|
Hello, when I try to build the app with external package using Xcode 15 beta 2 (Swift 5.9), it started throwing errors during compiling that package. Do you think it is the same problem?
|
|
I see, you need the func foo<T: RawRepresentable>(src: Any, _: T) where T.RawValue == Int {
if let x = src as? Int, let x = T(rawValue: x) {}
} |
|
Currently facing apparently the same issue on a huge codebase in Xcode 15.0 beta 2. There are a lot of source files in the arguments to |
|
@max-christian Try compiling with a recent snapshot. The pretty stack trace should be more informative with recent revisions and specify both the file and source location like the one I posted above. |
|
Useful to know how to switch toolchains to the snapshot, thanks @AnthonyLatsis. Though unfortunately the compile phase is fine on the snapshot so I'm no closer to finding the culprit. |
|
@max-christian Here's how I described figuring out which file was causing the issue in a private thread, in case you want to try a similar approach:
|
Huh, what an elusive bug. Have you tried an older snapshot? One other option that might catch the broken invariant before stuff is handed over to LLVM is |
Perhaps not elusive but just a bug that's been fixed between Xcode 15.0 beta 2 and the snapshot I used? If there's a possibility it's a bug that needs attention I can open a separate issue, as the line of code that crashed the compiler isn't an exact match for this issue: Thanks to @insidegui for the zero byte object file trick; that successfully narrowed it down to one source file. |
Thank you so much, I would have never discovered my issue without doing this! It helped me to discover that my code var networkError: some Error {
NSError(...)
}was not triggering any compiler errors/warnings, but it was crashing the compiler. All I had to do was change it to |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The following function crashes the compiler:
If, however, I make the following change, there is no crash:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Compiler should not crash.
Environment (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: