Document variance in strip #13677
Document variance in strip #13677
Conversation
Two variances in strip will remain, even after MSVC shenanigans settle: - Its default based on profile. - That it can sometimes make backtraces nonsensical. In my experience, people will complain to me if backtraces are fucked up, but sometimes it was their own decision to make the backtrace really bad. Inform them of this. Hopefully this also encourages people to report if their backtraces regress in some platform-dependent way without enabling `strip = "symbols"`, which we would want to know about.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @epage (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
rustbot
added
A-documenting-cargo-itself
| @@ -117,7 +117,9 @@ strip = "debuginfo" | |||
| ``` | |||
|
|
|||
| Possible string values of `strip` are `"none"`, `"debuginfo"`, and `"symbols"`. | |||
| The default is `"none"`. | |||
| The default is `"none"` by default, and `"debuginfo"` in release profile. | |||
There was a problem hiding this comment.
Similar to #13638, I don't think this is entirely correct. The default strip behavior depends on if debug is set (including overrides).
In #13257, we somewhat intentionally did not document this, as it should be a completely internal matter that should be transparent to the user. It is only running strip to deal with the particular way the standard library is distributed.
I'm not yet entirely convinced this should be documented, since it is a relatively complicated thing to explain to the user (something they shouldn't even need to know about) which could just contribute to confusion.
There was a problem hiding this comment.
...Frankly, I don't know why there are even two options if one affects how the other is interpreted.
There was a problem hiding this comment.
In any case, I do not believe these behaviors are actually completely internal matters that are transparent to the user, as the effective behavior seems to change wildly based on the target, host, or available binaries, e.g.
stripbinary isPATHdependent which breaks builds in MacOS rust#123114- 1.77 produced release binaries die w/ SIGKILL on macos 14.4 rust#122902
- Figure out pstack and Rust strip = "symbols" interaction oxidecomputer/helios#147
Perhaps we can make it one with rust-lang/rust#123151 but it isn't now.
| Be aware that stripping `"symbols"` may make backtraces incomprehensible, | ||
| depending on the platform. |
There was a problem hiding this comment.
For the most part, the cargo documentation doesn't dive into the particulars of explaining the different options and their consequences. That documentation should generally live in the rustc book (so we don't have to duplicate it in two remote places). Adding warnings about the consequences of stripping symbols would probably be appropriate over there (and seems good to include).
There was a problem hiding this comment.
It is my experience that people often do not actually click through, simply put.
Two variances in strip will remain, even after MSVC shenanigans settle:
In my experience, people will complain to me if backtraces are fucked up, but sometimes it was their own decision to make the backtrace really bad. Inform them of this. Hopefully this also encourages people to report if their backtraces regress in some platform-dependent way without enabling
strip = "symbols", which we would want to know about.