[WIP] Stabilize -Z pre-link-arg(s) as -C pre-link-arg(s)
#70505
Conversation
|
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
petrochenkov
added
the
T-compiler
|
cc @japaric |
jonas-schievink
added
A-linkage
|
Would you mind also updating the documentation at https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/codegen-options/index.md? It might be useful to clarify what it means by "prepend". I presume it means "arguments added before the arguments generated by rustc"? So the result is [pre-link-args] …generated args… [link-args] ?. |
|
r? @nagisa |
|
Is there a tracking issue for this feature? I have no concerns re implementation, but I think it should still go through the usual process (such as the FCP?) |
|
Are there docs for the flag? Would be good to add some user facing ones if not. |
|
There's no tracking issue and I'll add docs. |
Ha-ha, looks like the option parsing for both stable I'm not even surprised. I'll fix this stuff before the stabilization. |
petrochenkov
changed the title
-Z pre-link-arg(s) as -C pre-link-arg(s)-Z pre-link-arg(s) as -C pre-link-arg(s)
|
Closing for now. |
Do not lose or reorder user-provided linker arguments Linker arguments are potentially order-dependent, so the order in which `-C link-arg` and `-C link-args` options are passed to `rustc` should be preserved when they are passed further to the linker. Also, multiple `-C link-args` options are now appended to each other rather than overwrite each other. In other words, `-C link-arg=a -C link-args="b c" -C link-args="d e" -C link-arg=f` is now passed as `"a" "b" "c" "d" "e" "f"` and not as `"d" "e" "a" "f"`. Addresses rust-lang#70505 (comment).
…ti865 rustc_codegen_ssa: Refactor construction of linker arguments And add comments. This PR doesn't reorder any linker arguments and therefore shouldn't contain any observable changes. The next goal here is to - Factor out order-independent linker arguments in the compiler code and in target specifications and pass them together. Such arguments generally apply to the whole linking session or the produced linking result rather to individual object files or libraries. - Figure out where exactly among the remaining order-dependent arguments we should place customization points like `-C link-args` and `-Z pre-link-args`. - Possibly provide command line opt-outs for options that are currently passed unconditionally (like CRT objects or arguments defined by the target spec). - Document and stabilize the customization points that are not yet stable (rust-lang#70505).
|
@petrochenkov is there any plan to stabilize these features? |
The option is the same as
-C link-arg(s), except that the arguments are inserted at the start of the linker option list, rather than at the end.The feature was introduced in 2017 (#41971) to facilitate discussion about passing linker arguments (rust-embedded/wg#24). The conclusion seems to be "yep,
.cargo/configwithrustcflags in it is the way to go".This PR also accompanies #70501.