rustc_llvm: Fix flattened CLI args #131805
Merged
Conversation
This file contains hidden or 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
Fixes string manipulation errors introduced in rust-lang#130446.
rustbot
added
S-waiting-on-review
|
r? augie |
|
Failed to set assignee to
|
|
r? durin42 |
This comment has been minimized.
This comment has been minimized.
|
Thanks. I'm... actually not sure how rustc finished bootstrap on the LLVM 20 integration build with this error? It has built since then, right? |
workingjubilee
added
the
llvm-main
|
This only affects the command line portion in debug info on windows AFAIK. The only reason we found this was because we had tests for deterministic builds on windows, and the bad strings were sometimes garbage. |
|
huuuh. |
Comment on lines
+493
to
+499
| auto ArgsCppStr = std::string(ArgsCstrBuff + buffer_offset, | ||
| ArgsCstrBuffLen - buffer_offset); | ||
| auto i = 0; | ||
| while (i != std::string::npos) { | ||
| i = ArgsCppStr.find('\0', i + 1); | ||
| if (i != std::string::npos) | ||
| ArgsCppStr.replace(i, i + 1, " "); | ||
| ArgsCppStr.replace(i, 1, " "); |
There was a problem hiding this comment.
So, re-reading the reference about std::string::npos, I think I may have misunderstood something about it.
Why is it correct at all as part of a conditional expression like a while or if? It only takes on its magic "until the end of the string" meaning when used as an argument to std::string's functions, doesn't it? Which the control-flow expressions are not invocations of.
There was a problem hiding this comment.
https://cplusplus.com/reference/string/string/find/
Return Value
The position of the first character of the first match.
If no matches were found, the function returns string::npos.
npos isn't magic, it's in practice just a way to say -1. find() returns npos if something isn't found, and at that point we don't take this if / exit the loop.
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 17, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#129620 (Provide a more convinient way of developing rustc on NixOS) - rust-lang#131805 (rustc_llvm: Fix flattened CLI args) - rust-lang#131818 (Enable XRay instrumentation for LoongArch Linux targets) - rust-lang#131825 (SolverDelegate add assoc type for Infcx) - rust-lang#131833 (Add `must_use` to `CommandExt::exec`) - rust-lang#131835 (Do not run test where it cannot run) - rust-lang#131844 (Add mailmap entry for kobzol) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 17, 2024
Rollup merge of rust-lang#131805 - aeubanks:flat, r=durin42 rustc_llvm: Fix flattened CLI args Fixes string manipulation errors introduced in rust-lang#130446.
bors
added a commit
that referenced
this pull request
Sep 19, 2025
cg_llvm: Move target machine command-line quoting from C++ to Rust When this code was introduced in #130446 and #131805, it was complicated by the need to maintain compatibility with earlier versions of LLVM. Now that LLVM 20 is the baseline (#145071), we can do all of the quoting in pure Rust code, and pass two flat strings to LLVM to be used as-is. --- In this PR, my priority has been to preserve the existing behaviour as much as possible, without worrying too much about what the behaviour *should* be. (Though I did avoid a leading space before the first argument.)
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Sep 20, 2025
cg_llvm: Move target machine command-line quoting from C++ to Rust When this code was introduced in rust-lang/rust#130446 and rust-lang/rust#131805, it was complicated by the need to maintain compatibility with earlier versions of LLVM. Now that LLVM 20 is the baseline (rust-lang/rust#145071), we can do all of the quoting in pure Rust code, and pass two flat strings to LLVM to be used as-is. --- In this PR, my priority has been to preserve the existing behaviour as much as possible, without worrying too much about what the behaviour *should* be. (Though I did avoid a leading space before the first argument.)
Muscraft
pushed a commit
to Muscraft/rust
that referenced
this pull request
Sep 24, 2025
cg_llvm: Move target machine command-line quoting from C++ to Rust When this code was introduced in rust-lang#130446 and rust-lang#131805, it was complicated by the need to maintain compatibility with earlier versions of LLVM. Now that LLVM 20 is the baseline (rust-lang#145071), we can do all of the quoting in pure Rust code, and pass two flat strings to LLVM to be used as-is. --- In this PR, my priority has been to preserve the existing behaviour as much as possible, without worrying too much about what the behaviour *should* be. (Though I did avoid a leading space before the first argument.)
rust-cloud-vms bot
pushed a commit
to makai410/rustc_public
that referenced
this pull request
Oct 12, 2025
cg_llvm: Move target machine command-line quoting from C++ to Rust When this code was introduced in rust-lang/rust#130446 and rust-lang/rust#131805, it was complicated by the need to maintain compatibility with earlier versions of LLVM. Now that LLVM 20 is the baseline (rust-lang/rust#145071), we can do all of the quoting in pure Rust code, and pass two flat strings to LLVM to be used as-is. --- In this PR, my priority has been to preserve the existing behaviour as much as possible, without worrying too much about what the behaviour *should* be. (Though I did avoid a leading space before the first argument.)
bors
added a commit
that referenced
this pull request
Oct 22, 2025
Remove current code for embedding command-line args in PDB The compiler currently has code that will obtain a list of quoted command-line arguments, and pass it through to TargetMachine creation, so that the command-line args can be embedded in PDB output. This PR removes that code, due to subtle concerns that might not have been apparent when it was originally added. --- Those concerns include: - The entire command-line quoting process is repeated every time a target-machine-factory is created. In incremental builds this typically occurs 500+ times, instead of happening only once. The repeated quoting constitutes a large chunk of instructions executed in the `large-workspace` benchmark. - See #146804 (comment) for an example of the perf consequences of skipping all that work. - This overhead occurs even when building for targets or configurations that don't emit PDB output. - Command-line arguments are obtained in a way that completely bypasses the query system, which is a problem for the integrity of incremental compilation. - Fixing this alone is likely to inhibit incremental rebuilds for most or all CGUs, even in builds that don't emit PDB output. - Command-line arguments and the executable path are obtained in a way that completely bypasses the compiler's path-remapping system, which is a reproducibility hazard. - #128842 --- Relevant PRs: - #113492 - #130446 - #131805 - #146700 - #146973 Zulip thread: - https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Some.20PDB.20info.20bypasses.20the.20query.20system.20and.20path.20remapping/with/541432211 --- According to #96475, one of the big motivations for embedding the command-line arguments was to enable tools like Live++. [It appears that Live++ doesn't actually support Rust yet](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/embeded.20compiler.20args.20and.20--remap-path-prefix/near/523800010), so it's possible that there aren't any existing workflows for this removal to break. In the future, there could be a case for reintroducing some or all of this functionality, guarded behind an opt-in flag so that it doesn't cause problems for other users. But as it stands, the current implementation puts a disproportionate burden on other users and on compiler maintainers.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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.
Fixes string manipulation errors introduced in #130446.