Skip to content
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

sysroot spans still not printed, when remap-path-prefix is set with a custom path #74786

Open
infinity0 opened this issue Jul 26, 2020 · 5 comments
Labels
A-reproducibility Area: Reproducible / deterministic builds A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@infinity0
Copy link
Contributor

infinity0 commented Jul 26, 2020

The fix at the end of #53081 talks about remap-debuginfo in config.toml and /rustc/$hash, however in Debian we use --remap-path-prefix in RUSTFLAGS and /usr/src/rustc-$VERSION.

Results in 64 failing tests in [ui], in 1.44.1

@eddyb any ideas for a quick fix?

@infinity0 infinity0 added the C-bug Category: This is a bug. label Jul 26, 2020
@infinity0
Copy link
Contributor Author

This also causes 7 mir-opt-tests to fail, the ones that refer to $SRC_DIR. Example:

------------------------------------------
1       // MIR for `std::intrinsics::drop_in_place` before AddMovesForPackedDrops
2       
3       fn std::intrinsics::drop_in_place(_1: *mut std::vec::Vec<i32>) -> () {
-           let mut _0: ();                      // return place in scope 0 at $SRC_DIR/libcore/ptr/mod.rs:LL:COL
-           let mut _2: &mut std::vec::Vec<i32>; // in scope 0 at $SRC_DIR/libcore/ptr/mod.rs:LL:COL
-           let mut _3: ();                      // in scope 0 at $SRC_DIR/libcore/ptr/mod.rs:LL:COL
+           let mut _0: ();                      // return place in scope 0 at /usr/src/rustc-1.44.1/src/libcore/ptr/mod.rs:177:1: 181:2
+           let mut _2: &mut std::vec::Vec<i32>; // in scope 0 at /usr/src/rustc-1.44.1/src/libcore/ptr/mod.rs:177:1: 181:2
+           let mut _3: ();                      // in scope 0 at /usr/src/rustc-1.44.1/src/libcore/ptr/mod.rs:177:1: 181:2
7       
8           bb0: {
-               goto -> bb7;                     // bb0[0]: scope 0 at $SRC_DIR/libcore/ptr/mod.rs:LL:COL
+               goto -> bb7;                     // bb0[0]: scope 0 at /usr/src/rustc-1.44.1/src/libcore/ptr/mod.rs:177:1: 181:2
10          }
11      
12          bb1: {

-               return;                          // bb1[0]: scope 0 at $SRC_DIR/libcore/ptr/mod.rs:LL:COL
+               return;                          // bb1[0]: scope 0 at /usr/src/rustc-1.44.1/src/libcore/ptr/mod.rs:177:1: 181:2
14          }
15      
16          bb2 (cleanup): {

-               resume;                          // bb2[0]: scope 0 at $SRC_DIR/libcore/ptr/mod.rs:LL:COL
+               resume;                          // bb2[0]: scope 0 at /usr/src/rustc-1.44.1/src/libcore/ptr/mod.rs:177:1: 181:2
18          }
19      
20          bb3: {

@infinity0
Copy link
Contributor Author

If it's infeasible to fix this generally in rustc, I'd be happy to keep & maintain a Debian-specific hacky patch.

@infinity0
Copy link
Contributor Author

If I patch debuginfo_map_to() in src/bootstrap/lib.rs to hardcode our /usr/src/rustc-$VERSION path instead of /rustc/$hash it seems to work.

I was initially thrown off by the documentation of remap-debuginfo:

# Map all debuginfo paths for libstd and crates to `/rust/$sha/$crate/...`,
# generally only set for releases
#remap-debuginfo = false

This suggests that the mapping isn't applied to rustc's own artifacts (in the same way we have a separate debuginfo-level-std), but actually it in fact is applied to everything in src/bootstrap/bin/rustc.rs, which is what we want in Debian. I will file a PR to update the comment.

@nagisa
Copy link
Member

nagisa commented Jul 27, 2020

Closely related to #73167

@mark-i-m
Copy link
Member

Also seeing this in #73265 (comment)

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 28, 2020
config.toml.example: Update remap-debuginfo doc to be more general & accurate

This makes it more obvious that the work-around to rust-lang#74786 is actually correct, and a custom `--remap-path-prefix` isn't needed.

In fact the previous comment `/rustc/$hash/$crate` was wrong, it is not `$crate` but whatever path exists in the rustc source tree, so either `src/$crate` or `vendor/$crate`. I've fixed that as well to avoid future confusion.
@jyn514 jyn514 added the A-reproducibility Area: Reproducible / deterministic builds label Jun 16, 2023
@jieyouxu jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-compiletest Area: The compiletest test runner labels Aug 15, 2024
@jieyouxu jieyouxu added the A-testsuite Area: The testsuite used to check the correctness of rustc label Aug 15, 2024
@jieyouxu jieyouxu removed the A-compiletest Area: The compiletest test runner label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-reproducibility Area: Reproducible / deterministic builds A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants