Draft: Drop codegen unit name from comp name
Merge request reports
Activity
@refi64 Is this your suggestion? I think I am doing it wrong as my test failed. And because this may conflict with your MR !23 (merged) I didn't investigate further.
CC @wlozano
Does a fix really go better in dwarf2sources? Having specific knowledge of how Rust does compilation units is something that debhelper already has, it feels odd to also place that knowledge in dwarf2sources.
(To be clear, this isn't an issue with extracting the data; rustc really is writing compilation unit paths that have the
/@/...
suffix.)Interesting, so the new rust compiler available in Bookworm is writing the information differently, and this issue is rust specific, right?
In that case, I agree, it makes sense to have the logic here, as we are putting this kind of logic already here. If that is the right approach or not is a different discussion.
Of course, for this to make sense, the code and commit message should be clear about the context.
What do you think @daissi ?
Yes, the "new" rust compiler in bookworm adds this
/@/...
suffix to be sure codegen units cannot have identical DWARF entries (before this behavior was only on OSX, so not something we care about see https://github.com/rust-lang/rust/pull/92024).dwarf2sources
correctly extracts data, they're simply not usable in their current state. So, yes let's have the logic here.If I remember correctly, this current MR is not enough and works only for external sources, so we need to extend/improve it.
mentioned in merge request rust-coreutils!33 (merged)
added 6 commits
-
699e072a...f4ebdf6c - 4 commits from branch
apertis/v2024pre
- 2b2e8d39 - Drop codegen unit name from comp name
- f9413f3f - Bump changelog
-
699e072a...f4ebdf6c - 4 commits from branch
mentioned in merge request !26 (closed)
mentioned in issue infrastructure/apertis-issues#456 (closed)
Superseded by !27 (merged)