Skip to content

[DNM] workarounds for regression SR-12831 on master/5.3 since Feb 7th #32484

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

johnno1962
Copy link
Contributor

Hi Apple,

OK, so it’s a busy week but I thought I’d file a quick workaround I’ve had to use to get one of my repos johnno1962/SwiftTrace to be able to compile with a toolchain built from master & 5.3 branch. At the moment you get a Segmentation fault: 11 during module merge due to dereferencing a nullptr as detailed in the ticket. I've bisected the various recent downloadable toolchains and this dates back to commits on February 7th and looking at where it crashes it seems to be related to this new functionality cc: @rjmccall.

The problem declaration is this which is @convention(c) but actually a SwiftDecl:

       static var onEntry: @convention(c) (_ swizzle: Swizzle, _ returnAddress: UnsafeRawPointer,
           _ stackPointer: UnsafeMutablePointer<UInt64>) -> IMP? = {
               (swizzle, returnAddress, stackPointer) -> IMP? in
               // etc...

If I remove the @convention(c) it will compile but give an error at runtime. I need to store a pointer to a C function in a static. This has been compiling fine previously.

Works around SR-12831.

@johnno1962 johnno1962 changed the title [WIP] workarounds for regression SR-12831 on master/5.3 toolchains since Feb 7th [WIP] workarounds for regression SR-12831 on master/5.3 since Feb 7th Jun 21, 2020
@johnno1962 johnno1962 changed the title [WIP] workarounds for regression SR-12831 on master/5.3 since Feb 7th [DNM] workarounds for regression SR-12831 on master/5.3 since Feb 7th Jun 22, 2020
@@ -1380,8 +1380,9 @@ TypeConverter::TypeConverter(IRGenModule &IGM)
}

bool error = readLegacyTypeInfo(*fs, path);
if (error)
llvm::report_fatal_error("Cannot read '" + path + "'");
// avoids error: "<unknown>:1:1: Cannot read '/usr/lib/swift/layouts-x86_64.yaml'"
Copy link
Contributor

@CodaFi CodaFi Jun 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proper way to "work around" these is to ensure that your resource directory is properly formed. If you have built a custom toolchain, you will need to verify that these layout back-compat files are present under My-Custom-Toolchain.xctoolchain/usr/lib/swift.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also note that these paths are subject to VFS remapping, and are sensitive to the -resource-dir flag.

Copy link
Contributor

@CodaFi CodaFi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your original crash is in Clang. I suspect you are having trouble with the coherency of a generated clang module if the AST reader is unable to parse something. You could try removing the module cache and rebuilding. But turning off huge portions of the deserialization code is not the right answer.

@johnno1962
Copy link
Contributor Author

Thanks for triaging this @CodaFi, I’ve downloaded the Xcode 12 beta and cannot reproduce this problem. I’ll keep an eye on it and file a radar if it makes it into Xcode 12. Sorry for the noise ☺️.

@johnno1962 johnno1962 closed this Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants