Workaround ODR violations in enum debuginfo #27689
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When using a generic enum type that was defined in an external crate, our debuginfo currently claims that the concrete type (e.g. Option<i32>) was defined in the current crate, where it was first used. This means that if there are multiple crates that all use, for example, Option<i32> values, they'll have conflicting debuginfo, each crate claiming to have defined that type. This doesn't cause problems in regular builds, but with LTO enabled, LLVM complains because it tries to merge the debuginfo for those types and sees the ODR violations. Since I couldn't find a way to get the file info for the external crate that actually defined the enum, I'm working around the issue by using "<unknown>" as the file for enum types. We'll want to re-visit and fix this later, but this at least this fixes the ICE. And with the file being unknown instead of wrong, the debuginfo isn't really worse than before either. Fixes rust-lang#26447
|
r? @jroesch (rust_highfive has picked a reviewer for you, use r? to override) |
|
@dotdash: From your point view, is there a reason why you'd rather associate enum types to a file named |
|
Unfortunately, unless I missed something, this kind of debuginfo requires file metadata, otherwise I would have just removed it. |
|
Yes, I think I remember now that I've run into this oddity myself some time ago. We should try and this restriction removed from LLVM. |
|
@bors: r+ |
|
📌 Commit d17d2dd has been approved by |
bors
added a commit
that referenced
this pull request
Aug 16, 2015
When using a generic enum type that was defined in an external crate, our debuginfo currently claims that the concrete type (e.g. Option<i32>) was defined in the current crate, where it was first used. This means that if there are multiple crates that all use, for example, Option<i32> values, they'll have conflicting debuginfo, each crate claiming to have defined that type. This doesn't cause problems in regular builds, but with LTO enabled, LLVM complains because it tries to merge the debuginfo for those types and sees the ODR violations. Since I couldn't find a way to get the file info for the external crate that actually defined the enum, I'm working around the issue by using "<unknown>" as the file for enum types. We'll want to re-visit and fix this later, but this at least this fixes the ICE. And with the file being unknown instead of wrong, the debuginfo isn't really worse than before either. Fixes #26447
|
@pnkfelix it was the last one I'm aware of. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using a generic enum type that was defined in an external crate,
our debuginfo currently claims that the concrete type (e.g. Option)
was defined in the current crate, where it was first used.
This means that if there are multiple crates that all use, for example,
Option values, they'll have conflicting debuginfo, each crate
claiming to have defined that type. This doesn't cause problems in
regular builds, but with LTO enabled, LLVM complains because it tries to
merge the debuginfo for those types and sees the ODR violations.
Since I couldn't find a way to get the file info for the external crate
that actually defined the enum, I'm working around the issue by using
"" as the file for enum types. We'll want to re-visit and fix
this later, but this at least this fixes the ICE. And with the file
being unknown instead of wrong, the debuginfo isn't really worse than
before either.
Fixes #26447