rustc: Tweak filenames encoded into metadata #54626
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
This commit is a fix for rust-lang#54408 where on nightly right now whenever generics are inlined the path name listed for the inlined function's debuginfo is a relative path to the cwd, which surely doesn't exist! Previously on beta/stable the debuginfo mentioned an absolute path which still didn't exist, but more predictably didn't exist. The change between stable/nightly is that nightly is now compiled with `--remap-path-prefix` to give a deterministic prefix to all rustc-generated paths in debuginfo. By using `--remap-path-prefix` the previous logic would recognize that the cwd was remapped, causing the original relative path name of the standard library to get emitted. If `--remap-path-prefix` *wasn't* passed in then the logic would create an absolute path name and then create a new source file entry. The fix in this commit is to apply the "recreate the source file entry with an absolute path" logic a bit more aggresively. If the source file's name was remapped then we don't touch it, but otherwise we always take the working dir (which may have been remapped) and then join it to the file to ensure that we process all relative file names as well. The end result is that the standard library should have an absolute path for all file names in debuginfo (using our `--remap-path-prefix` argument) as it does on stable after this patch. Closes rust-lang#54408
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Hm, this might regress for an existing use case (cc @jsgf). I'll take a closer look next week. |
|
Oh I do think it would work! It's not trivial though, unfortunately, getting it working with cargo and all. I figured that this version was more consistent with non-remapped paths, but it would break if the remap path prefix isn't absolute |
|
Ah sorry, I didn't manage to review this properly yet and I'll be on PTO for the next two weeks... |
|
OK, after looking at it more closely, I think this change is fine after all. I hope it doesn't break anything that I'm overlooking. Sorry for the delay. @bors r+ |
|
📌 Commit 63c471e has been approved by |
bors
added
S-waiting-on-bors
pietroalbini
added a commit
to pietroalbini/rust
that referenced
this pull request
Oct 23, 2018
…aelwoerister rustc: Tweak filenames encoded into metadata This commit is a fix for rust-lang#54408 where on nightly right now whenever generics are inlined the path name listed for the inlined function's debuginfo is a relative path to the cwd, which surely doesn't exist! Previously on beta/stable the debuginfo mentioned an absolute path which still didn't exist, but more predictably didn't exist. The change between stable/nightly is that nightly is now compiled with `--remap-path-prefix` to give a deterministic prefix to all rustc-generated paths in debuginfo. By using `--remap-path-prefix` the previous logic would recognize that the cwd was remapped, causing the original relative path name of the standard library to get emitted. If `--remap-path-prefix` *wasn't* passed in then the logic would create an absolute path name and then create a new source file entry. The fix in this commit is to apply the "recreate the source file entry with an absolute path" logic a bit more aggresively. If the source file's name was remapped then we don't touch it, but otherwise we always take the working dir (which may have been remapped) and then join it to the file to ensure that we process all relative file names as well. The end result is that the standard library should have an absolute path for all file names in debuginfo (using our `--remap-path-prefix` argument) as it does on stable after this patch. Closes rust-lang#54408
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Oct 24, 2018
…aelwoerister rustc: Tweak filenames encoded into metadata This commit is a fix for rust-lang#54408 where on nightly right now whenever generics are inlined the path name listed for the inlined function's debuginfo is a relative path to the cwd, which surely doesn't exist! Previously on beta/stable the debuginfo mentioned an absolute path which still didn't exist, but more predictably didn't exist. The change between stable/nightly is that nightly is now compiled with `--remap-path-prefix` to give a deterministic prefix to all rustc-generated paths in debuginfo. By using `--remap-path-prefix` the previous logic would recognize that the cwd was remapped, causing the original relative path name of the standard library to get emitted. If `--remap-path-prefix` *wasn't* passed in then the logic would create an absolute path name and then create a new source file entry. The fix in this commit is to apply the "recreate the source file entry with an absolute path" logic a bit more aggresively. If the source file's name was remapped then we don't touch it, but otherwise we always take the working dir (which may have been remapped) and then join it to the file to ensure that we process all relative file names as well. The end result is that the standard library should have an absolute path for all file names in debuginfo (using our `--remap-path-prefix` argument) as it does on stable after this patch. Closes rust-lang#54408
pietroalbini
added a commit
to pietroalbini/rust
that referenced
this pull request
Oct 25, 2018
…aelwoerister rustc: Tweak filenames encoded into metadata This commit is a fix for rust-lang#54408 where on nightly right now whenever generics are inlined the path name listed for the inlined function's debuginfo is a relative path to the cwd, which surely doesn't exist! Previously on beta/stable the debuginfo mentioned an absolute path which still didn't exist, but more predictably didn't exist. The change between stable/nightly is that nightly is now compiled with `--remap-path-prefix` to give a deterministic prefix to all rustc-generated paths in debuginfo. By using `--remap-path-prefix` the previous logic would recognize that the cwd was remapped, causing the original relative path name of the standard library to get emitted. If `--remap-path-prefix` *wasn't* passed in then the logic would create an absolute path name and then create a new source file entry. The fix in this commit is to apply the "recreate the source file entry with an absolute path" logic a bit more aggresively. If the source file's name was remapped then we don't touch it, but otherwise we always take the working dir (which may have been remapped) and then join it to the file to ensure that we process all relative file names as well. The end result is that the standard library should have an absolute path for all file names in debuginfo (using our `--remap-path-prefix` argument) as it does on stable after this patch. Closes rust-lang#54408
bors
added a commit
that referenced
this pull request
Oct 26, 2018
rustc: Tweak filenames encoded into metadata This commit is a fix for #54408 where on nightly right now whenever generics are inlined the path name listed for the inlined function's debuginfo is a relative path to the cwd, which surely doesn't exist! Previously on beta/stable the debuginfo mentioned an absolute path which still didn't exist, but more predictably didn't exist. The change between stable/nightly is that nightly is now compiled with `--remap-path-prefix` to give a deterministic prefix to all rustc-generated paths in debuginfo. By using `--remap-path-prefix` the previous logic would recognize that the cwd was remapped, causing the original relative path name of the standard library to get emitted. If `--remap-path-prefix` *wasn't* passed in then the logic would create an absolute path name and then create a new source file entry. The fix in this commit is to apply the "recreate the source file entry with an absolute path" logic a bit more aggresively. If the source file's name was remapped then we don't touch it, but otherwise we always take the working dir (which may have been remapped) and then join it to the file to ensure that we process all relative file names as well. The end result is that the standard library should have an absolute path for all file names in debuginfo (using our `--remap-path-prefix` argument) as it does on stable after this patch. Closes #54408
|
☀️ Test successful - status-appveyor, status-travis |
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.
This commit is a fix for #54408 where on nightly right now whenever
generics are inlined the path name listed for the inlined function's
debuginfo is a relative path to the cwd, which surely doesn't exist!
Previously on beta/stable the debuginfo mentioned an absolute path which
still didn't exist, but more predictably didn't exist.
The change between stable/nightly is that nightly is now compiled with
--remap-path-prefixto give a deterministic prefix to allrustc-generated paths in debuginfo. By using
--remap-path-prefixtheprevious logic would recognize that the cwd was remapped, causing the
original relative path name of the standard library to get emitted. If
--remap-path-prefixwasn't passed in then the logic would create anabsolute path name and then create a new source file entry.
The fix in this commit is to apply the "recreate the source file entry
with an absolute path" logic a bit more aggresively. If the source
file's name was remapped then we don't touch it, but otherwise we always
take the working dir (which may have been remapped) and then join it to
the file to ensure that we process all relative file names as well.
The end result is that the standard library should have an absolute path
for all file names in debuginfo (using our
--remap-path-prefixargument) as it does on stable after this patch.
Closes #54408