Don't hash executable filenames on apple platforms. #8329
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
rust-highfive
added
the
S-waiting-on-review
ehuss
commented
Jun 4, 2020
Comment on lines
630
to
+632
| || (unit.target.is_executable() && short_name.starts_with("wasm32-")) | ||
| || (unit.target.is_executable() && short_name.contains("msvc"))) | ||
| || (unit.target.is_executable() && short_name.contains("msvc")) | ||
| || (unit.target.is_executable() && short_name.contains("-apple-"))) |
There was a problem hiding this comment.
Should this maybe be changed to a CfgExpr test? I'm becoming more uneasy with anything that inspects the target triple, since that doesn't work for JSON targets, and generally seems a little sloppy.
|
If we believe this is not a common use case, could we do this everywhere, rather than adding one more case to the list of cases? Alternatively, is there some way we can emit a |
|
@bors: r+ Since this is fixing a regression in rust-lang/rust I'm going to go ahead and approve so we can land this in. I think @joshtriplett is right thought that if 2/3 major platforms don't do this then we should back it out for all platforms. I also agree with you @ehuss that we should ideally not look at the target string at all in Cargo... |
|
📌 Commit f975c2e has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-azure |
ehuss
pushed a commit
to ehuss/cargo
that referenced
this pull request
Jun 5, 2020
Don't hash executable filenames on apple platforms. Due to some recent changes to the backtrace crate, backtraces on apple platforms haven't been working (they are missing line/filename information). The reason is that previously libbacktrace would hunt through the directory for any matching file in the `.dSYM` directory. The new implementation expects a file matching the executable name exactly (which no longer includes the hash because Cargo renames it). The solution here is to not include a hash in the executable filename. This matches the behavior on Windows which does it for a similar reason (paths are embedded in pdb files). The downside is that switching between different settings (like different features) causes Cargo to rebuild the binary each time. I don't think this is a particularly common use case, at least I've not heard any complaints about this behavior on Windows. Fixes rust-lang/rust#72550
Merged
Merged
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 11, 2020
Update cargo 15 commits in 40ebd52206e25c7a576ee42c137cc06a745a167a..1ec223effbbbf9fddd3453cdcae3a96a967608eb 2020-06-01 22:35:00 +0000 to 2020-06-09 20:03:14 +0000 - Default values for `readme` if not specified (rust-lang/cargo#8277) - Fix tree completions. (rust-lang/cargo#8342) - Support `{prefix}` and `{lowerprefix}` markers in `config.json` `dl` key (rust-lang/cargo#8267) - Add environment variables to identify the binary and crate name (rust-lang/cargo#8270) - Bump to 0.47.0, update changelog (rust-lang/cargo#8336) - Nits: Remove unneeded mut and loop (rust-lang/cargo#8334) - 1.45 beta backports (rust-lang/cargo#8331) - Better error message when passing in relative path to Workspace::new (rust-lang/cargo#8321) - Don't hash executable filenames on apple platforms. (rust-lang/cargo#8329) - fix clippy warnings (rust-lang/cargo#8324) - Require latest libgit2 to pull in bugfixes (rust-lang/cargo#8320) - Fix an accidental raw access of field (rust-lang/cargo#8319) - Use mem::take to replace with Default values (rust-lang/cargo#8314) - Allow Windows dylibs without dll suffix. (rust-lang/cargo#8310) - Show alias in help message (rust-lang/cargo#8307)
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this pull request
Jul 7, 2020
Pkgsrc changes: * None. Upstream changes: Version 1.44.1 (2020-06-18) =========================== * [rustfmt accepts rustfmt_skip in cfg_attr again.][73078] * [Don't hash executable filenames on apple platforms, fixing backtraces.] [cargo/8329] * [Fix crashes when finding backtrace on macOS.][71397] * [Clippy applies lint levels into different files.][clippy/5356] [71397]: rust-lang/rust#71397 [73078]: rust-lang/rust#73078 [cargo/8329]: rust-lang/cargo#8329 [clippy/5356]: rust-lang/rust-clippy#5356
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.
Due to some recent changes to the backtrace crate, backtraces on apple platforms haven't been working (they are missing line/filename information). The reason is that previously libbacktrace would hunt through the directory for any matching file in the
.dSYMdirectory. The new implementation expects a file matching the executable name exactly (which no longer includes the hash because Cargo renames it).The solution here is to not include a hash in the executable filename. This matches the behavior on Windows which does it for a similar reason (paths are embedded in pdb files).
The downside is that switching between different settings (like different features) causes Cargo to rebuild the binary each time. I don't think this is a particularly common use case, at least I've not heard any complaints about this behavior on Windows.
Fixes rust-lang/rust#72550