d17d2dd48e
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 |
||
---|---|---|
.. | ||
compiler-rt@58ab642c30 | ||
compiletest | ||
doc | ||
driver | ||
error-index-generator | ||
etc | ||
grammar | ||
jemalloc@e24a1a025a | ||
liballoc | ||
libarena | ||
libbacktrace | ||
libcollections | ||
libcollectionstest | ||
libcore | ||
libcoretest | ||
libflate | ||
libfmt_macros | ||
libgetopts | ||
libgraphviz | ||
liblibc | ||
liblog | ||
librand | ||
librbml | ||
librustc | ||
librustc_back | ||
librustc_bitflags | ||
librustc_borrowck | ||
librustc_data_structures | ||
librustc_driver | ||
librustc_lint | ||
librustc_llvm | ||
librustc_privacy | ||
librustc_resolve | ||
librustc_trans | ||
librustc_typeck | ||
librustc_unicode | ||
librustdoc | ||
libserialize | ||
libstd | ||
libsyntax | ||
libterm | ||
libtest | ||
llvm@874dc4ee4c | ||
rt | ||
rust-installer@c37d3747da | ||
rustbook | ||
rustllvm | ||
test | ||
snapshots.txt |