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

rustc: Tweak filenames encoded into metadata #54626

Merged
merged 1 commit into from
Oct 26, 2018

Conversation

alexcrichton
Copy link
Member

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

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
Copy link
Collaborator

r? @michaelwoerister

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 27, 2018
@michaelwoerister
Copy link
Member

Hm, this might regress for an existing use case (cc @jsgf). I'll take a closer look next week.
@alexcrichton, the solution proposed in #54408 (comment) wouldn't work here?

@alexcrichton
Copy link
Member Author

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

@michaelwoerister
Copy link
Member

Ah sorry, I didn't manage to review this properly yet and I'll be on PTO for the next two weeks...

@michaelwoerister
Copy link
Member

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+

@bors
Copy link
Contributor

bors commented Oct 23, 2018

📌 Commit 63c471e has been approved by michaelwoerister

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 23, 2018
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
Copy link
Contributor

bors commented Oct 26, 2018

⌛ Testing commit 63c471e with merge bf962e2...

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
@bors
Copy link
Contributor

bors commented Oct 26, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing bf962e2 to master...

@bors bors merged commit 63c471e into rust-lang:master Oct 26, 2018
@alexcrichton alexcrichton deleted the dwarf-generics branch October 29, 2018 01:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DWARF information does not contain absolute file locations for generics
4 participants