-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Support --print KIND=PATH
command line syntax
#113780
Conversation
r? @b-naber (rustbot has picked a reviewer for you, use r? to override) |
sess.note_without_error(format!("native-static-libs: {}", &lib_args.join(" "))); | ||
|
||
match out { | ||
OutFileName::Real(_) => out.overwrite(&lib_args.join(" "), sess), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel that just writing the arguments here could potentially be confusing without the output that emit_note(errors::StaticLibraryNativeArtifacts)
would print to stdout. Can we either include that note or maybe don't write anything here at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. How about keeping a sess.emit_note
that informs you that it wrote the native-static-libs to a file? Similar to what #76843 did for long type names -- write the unadorned information to a file (which is the most useful for tooling) and also write an informative note among the compiler diagnostics to provide context.
-
rustc --print=native-static-libs ...
(same as today)note: Link against the following native artifacts when linking against this static library. The order and any duplication can be significant on some platforms. note: native-static-libs: -lglib-2.0 -lbar_cli -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc -lsystemd -lfoo_cli
-
rustc --print=native-static-libs=./native-static-libs.txt ...
note: Native artifacts to link against have been written to ./native-static-libs.txt. The order and any duplication can be significant on some platforms.
native-static-libs.txt:
-lglib-2.0 -lbar_cli -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc -lsystemd -lfoo_cli
6e7346b
to
4d5134f
Compare
@@ -1467,7 +1467,12 @@ fn print_native_static_libs( | |||
} | |||
|
|||
match out { | |||
OutFileName::Real(_) => out.overwrite(&lib_args.join(" "), sess), | |||
OutFileName::Real(path) => { | |||
out.overwrite(&lib_args.join(" "), sess); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you move this into the if branch? Also I'm not sure what exact form lib_args
has and whether it's straightforward to find the native artifacts in the file after reading the note on stdout, would it maybe be better to write this to the file: "native-static-libs: {}", &lib_args.join(" ")
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah nvm, I don't think this is necessary.
Can you maybe open a PR to update https://doc.rust-lang.org/rustc/command-line-arguments.html after this is merged, please? @bors r+ rollup |
Support `--print KIND=PATH` command line syntax As is already done for `--emit KIND=PATH` and `-L KIND=PATH`. In the discussion of rust-lang#110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o` path to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`. I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](https://github.com/facebook/buck2/blob/d43cf3a51a31f00be2c2248e78271b0fef0452b4/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system. From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". https://github.com/rust-lang/cargo/blob/31eda6f7c360d9911f853b3014e057db61238f3e/src/cargo/core/compiler/build_context/target_info.rs#L242 (FYI `@weihanglo` as you dealt with this recently in rust-lang/cargo#11633.) Mentioning reviewers active in rust-lang#110785: `@fee1-dead` `@jyn514` `@bjorn3`
@bors r- rollup=maybe |
@bors r=b-naber |
📌 Commit c9b04d1bc862095e2799dfeaa1671d76021aceb6 has been approved by It is now in the queue for this repository. |
This comment has been minimized.
This comment has been minimized.
This introduces a bit of code duplication, but we don't have the build_output_filenames in the CrateName arm and this seems a little cleaner overall.
@bors r=b-naber |
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#113380 (style-guide: clean up "must"/"should"/"may") - rust-lang#113723 (Resurrect: rustc_llvm: Add a -Z `print-codegen-stats` option to expose LLVM statistics.) - rust-lang#113780 (Support `--print KIND=PATH` command line syntax) - rust-lang#113810 (Make {Rc,Arc}::allocator associated functions) - rust-lang#113907 (Minor improvements to Windows TLS dtors) Failed merges: - rust-lang#113392 (style-guide: Some cleanups from the fmt-rfcs repo history) r? `@ghost` `@rustbot` modify labels: rollup
Not a compiler member, but shouldn't this have gone through a compiler FCP since it's insta-stable or be gated as an unstable feature? @rustbot label +I-compiler-nominated |
rust-lang#113780 should have gone through an MCP+FCP but wasn't, but instead of reverting the original PR, this PR just make that new option unstable.
…e, r=jackh726 Make `--print` with path unstable rust-lang#113780 should have gone through an MCP+FCP but wasn't, but instead of reverting the original PR, this PR just make that new option unstable. [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202023-07-27/near/379199738) cc `@dtolnay`
* Dynamic for smir * Optimize format usage Per #112156, using `&` in `format!` may cause a small perf delay, so I tried to clean up one module at a time format usage. This PR includes a few removals of the ref in format (they do compile locally without the ref), as well as a few format inlining for consistency. * compiler: Hermit targets: Remove pre-link args. These pre-link args are remains from Hermit's old C version. We don't need them and we have no reason to override the defaults here. See ld [1] for details. [1]: https://sourceware.org/binutils/docs/ld/Options.html Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * compiler: Hermit targets: Sort base fields by declaration Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * compiler: Hermit targets: Use functional update syntax instead of mutating the base. Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * compiler: Add `riscv64gc-unknown-hermit` target Co-authored-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * compiler: Add `*-unknown-hermit` documentation Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * Remove redundant note. This came from x86_64-unknown-none and doesn't make sense here. * Add clarification about build-std and using newer instructions. * new unstable option: -Zwrite-long-types-to-disk This option guards the logic of writing long type names in files and instead using short forms in error messages in rustc_middle/ty/error behind a flag. The main motivation for this change is to disable this behaviour when running ui tests. This logic can be triggered by running tests in a directory that has a long enough path, e.g. /my/very-long-path/where/rust-codebase/exists/ This means ui tests can fail depending on how long the path to their file is. Some ui tests actually rely on this behaviour for their assertions, so for those we enable the flag manually. * coverage: Obtain the `__llvm_covfun` section name outside a per-function loop This section name is always constant for a given target, but obtaining it from LLVM requires a few intermediate allocations. There's no need to do so repeatedly from inside a per-function loop. * interpret: support projecting into Place::Local without force_allocation * Explain what the heck is going on with this lifetime remapping business * builtin_macros: expect raw strings too `expr_to_string` allows raw strings through so this code should be expected to handle those. Signed-off-by: David Wood <david@davidtw.co> * Some documentation nits * Fix missing attribute merge on glob foreign re-exports * Add regression test for #113982 * Hide `ToString` implementations that specialize the default ones The status quo is highly confusing, since the overlap is not apparent, and specialization is not a feature of Rust. This addresses #87545; I'm not certain if it closes it, since that issue might also be trackign a *general* solution for hiding specializing impls automatically. * borrowck/errors: fix i18n error in delayed bug During borrowck, the `MultiSpan` from a buffered diagnostic is cloned and used to emit a delayed bug indicating a diagnostic was buffered - when the buffered diagnostic is translated, then the cloned `MultiSpan` may contain labels which can only render with the diagnostic's arguments, but the delayed bug being emitted won't have those arguments. Adds a function which clones `MultiSpan` without also cloning the contained labels, and use this function when creating the buffered diagnostic delayed bug. Signed-off-by: David Wood <david@davidtw.co> * Add missing documentation for `Session::time` * If re-export is private, get the next item until a public one is found or expose the private item directly * Add regression test for #81141 * Improve code readability * Extend issue-81141-private-reexport-in-public-api test to cover more cases * Rename `first_not_private` into `first_non_private` * Correctly handle `super` and `::` * Add test for private items * Add support for `--document-hidden-items` in `first_non_private` * Add test for `--document-hidden-items` * Re-add missing generics in `first_non_private` * Add regression test for generics reexport of private import * Remove needs for transmute * Revert "Remove needs for transmute" This reverts commit ea9a17b9995b7a076283777b7d462a360fece2d6. * Cache qpath first public result * Fix span for punnycode * Explain RPITs in the way they actually work * lcnr's suggestions Co-authored-by: lcnr <rust@lcnr.de> * validate `doc(masked)` * compiler: Add `x86_64-unikraft-linux-musl` target Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * compiler: Add `*-unikraft-linux-musl` documentation Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * bootstrap: Don't bundle musl on Unikraft Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * `unix::init`: Handle `ENOSYS` from `poll` on Unikraft. Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * `unix::init`: Don't use `signal` on Unikraft. Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> * Update cargo * fix(resolve): skip panic when resolution is dummy * resolve: ensure compile failed when has dummy or ambiguous * typos * delete [allow(...)] from issue #74838 * remove additional [allow(unused_unsafe)] * bootstrap: Define CMake platform if DragonFly. CMAKE_SYSTEM_NAME is defined on a cross build if the target is recognized. Without this explicit definition cmake will assume that we're building for the host platform which can bring in unwanted compiler and linker flags. Also, add a warning on cross builds with unknown target to aid in cross builds for future platforms. * docs(LazyLock): add example pass local LazyLock variable to struct Signed-off-by: DragonBillow <DragonBillow@outlook.com> * factor out more stable impls * Added recursive checking back up to see if a `Clone` suggestion would be helpful. * extract common code * builtin_macros: raw str in diagnostic output If a raw string was used in the `env!` invocation, then it should also be shown in the diagnostic messages as a raw string. Signed-off-by: David Wood <david@davidtw.co> * Add regression test for invalid unused const in method The warning can be reproduced with 1.63 but not with 1.64. $ rustc +1.63 tests/ui/lint/unused/const-local-var.rs warning: constant `F` is never used --> tests/ui/lint/unused/const-local-var.rs:14:9 | 14 | const F: i32 = 2; | ^^^^^^^^^^^^^^^^^ | = note: `#[warn(dead_code)]` on by default $ rustc +1.64 tests/ui/lint/unused/const-local-var.rs Add a regression test to prevent the problem from re-appearing. * clippy: `env!` invocations can't be b"" literals Signed-off-by: David Wood <david@davidtw.co> * write-long-types-to-disk: update tests * interpret: refactor projection code to work on a common trait, and use that for visitors * interpret: read_discriminant: only return VariantIdx * bless more * add some sanity checks in write_immediate_no_validate * Suggest `{Option,Result}::as_ref()` instead of `cloned()` in some cases * Remove some arguments that are always the same * Inline a function that is only used once * Remove a redundant field * Improve performance of `first_non_private` * Try explaining where `Inner` is in the signature better * Use a builder instead of boolean/option arguments * abi: unsized field in union - assert to delay bug Unions cannot have unsized fields, and as such, layout computation for unions asserts that each union field is sized (as this would normally have halted compilation earlier). However, if a generator ends up with an unsized local - a circumstance in which an error will always have been emitted earlier, for example, if attempting to dereference a `&str` - then the generator transform will produce a union with an unsized field. Since #110107, later passes will be run, such as constant propagation, and can attempt layout computation on the generator, which will result in layout computation of `str` in the context of it being a field of a union - and so the aforementioned assertion would cause an ICE. It didn't seem appropriate to try and detect this case in the MIR body and skip this specific pass; tainting the MIR body or delaying a bug from the generator transform (or elsewhere) wouldn't prevent this either (as neither would prevent the later pass from running); and tainting when the deref of `&str` is reported, if that's possible, would unnecessarily prevent potential other errors from being reported later in compilation, and is very tailored to this specific case of getting a unsized type in a generator. Given that this circumstance can only happen when an error should have already been reported, the correct fix appears to be just changing the assert to a delayed bug. This will still assert if there is some circumstance where this occurs and no error has been reported, but it won't crash the compiler in this instance. Signed-off-by: David Wood <david@davidtw.co> * Normalize the RHS of an unsize goal * Make sure to detect trait upcasting coercion even after normalization * Restore tuple unsizing feature gate * Consolidate trait upcasting and unsize into one normalization * CI: fix CMake installation for 32 and 64bit `dist` Linux * Add help for crate arg when crate name is invalid * Make everything builtin! * Remove credential providers from bootstrap since they are now built-in to the Cargo binary * Split nested GHA groups instead of panicking * interpret: make write functions generic over the place type * interpret: make read functions generic over operand type * make MPlaceTy non-Copy * Remove -Z diagnostic-width * inline format!() args from rustc_codegen_llvm to the end (4) r? @WaffleLapkin * Optimize `AtomicBool` for target that don't support byte-sized atomics `AtomicBool` is defined to have the same layout as `bool`, which means that we guarantee that it has a size of 1 byte. However on certain architectures such as RISC-V, LLVM will emulate byte atomics using a masked CAS loop on an aligned word. We can take advantage of the fact that `bool` only ever has a value of 0 or 1 to replace `swap` operations with `and`/`or` operations that LLVM can lower to word-sized atomic `and`/`or` operations. This takes advantage of the fact that the incoming value to a `swap` or `compare_exchange` for `AtomicBool` is often a compile-time constant. * Remove `Parser::desugar_doc_comments`. It's currently stored twice: once in `Parser`, once in the `TokenStream` within `Parser`. We only need the latter. * Add `sym::iter_mut` + `sym::as_mut_ptr` * rustdoc: stylistic changes * rustdoc: fix cross-crate impl-Sized * Don't treat negative trait predicates as always knowable * Tweak `Parser::look_ahead`. It doesn't really matter what the `desugar_doc_comments` argument is here, because in practice we never look ahead through doc comments. Changing it to `cursor.desugar_doc_comments` will allow some follow-up simplifications. * Remove `desugar_doc_comments` arguments from `TokenCursor::{inlined_,}next`. Because it's now always `self.desugar_doc_comments`. * Add a comment to `TokenCursor::desugar_doc_comments`. Useful information that took me some time to discern. * add tidy check that forbids issue ui test filenames * add stable NullaryOp * Make `x test src/tools/rustfmt --bless` format rustfmt with the freshly built in-tree version * Bump syn now that it doesn't affect diagnostics anymore * Bump syn dependency * valtree: a bit of cleanup * compiletest: remove ci-specific remap-path-prefix Now that we have fixed the underlying cause of long type name inconsistencies in #113893, we can remove the remap-path-prefix logic from CI * Regression test `println!()` panic message on `ErrorKind::BrokenPipe` No existing test failed if the [`panic!()`][1] of the `println!()` family of functions was removed, or if its message was changed. So add such a test. [1] https://github.com/rust-lang/rust/blob/104f4300cfddbd956e32820ef202a732f06ec848/library/std/src/io/stdio.rs#L1007-L1009 * docs: fmt::Debug*: Fix comments for finish method. In the code sample for the `finish` method on `DebugList`, `DebugMap`, and `DebugSet`, refer to finishing the list, map, or set, rather than struct as it did. * Add Param ty to SMIR * Add Bound ty to SMIR * Have a better file name than just the issue id * Fix regression for private in public * Replace in-tree `rustc_apfloat` with the new version of the crate * Fix miri * Remove unused NCSA license * replace atty crate with std's isTerminal * Squelch a noisy rustc_expand unittest * Add test case for #109567 * Add tests for #102403 and #113407 * Dont pass -Zwrite-long-types-to-disk=no for ui-fulldeps --stage=1 * Unite bless environment variables under `RUSTC_BLESS` Currently, Clippy, Miri, Rustfmt, and rustc all use an environment variable to indicate that output should be blessed, but they use different variable names. In order to improve consistency, this patch applies the following changes: - Emit `RUSTC_BLESS` within `prepare_cargo_test` so it is always available - Change usage of `MIRI_BLESS` in the Miri subtree to use `RUSTC_BLESS` - Change usage of `BLESS` in the Clippy subtree to `RUSTC_BLESS` - Change usage of `BLESS` in the Rustfmt subtree to `RUSTC_BLESS` - Adjust the blessable test in `rustc_errors` to use this same convention - Update documentation where applicable Any tools that uses `RUSTC_BLESS` should check that it is set to any value other than `"0"`. * Update LLVM submodule This adds rust-lang/llvm-project#148. * Fix URL for `rmatches` * Simplify the `ttdelim_span` test. The existing code is a very complex and inefficient way to the get the span of the last token. * Replace `into_trees` with `trees` in a test. There's no need for token tree cloning here. * Use `TokenStream::trees` instead of `into_trees` for attributes. This avoids cloning some token trees. A couple of `clone` calls were inserted, but only on some paths, and the next commit will remove them. * Make `TokenTree::uninterpolate` take `&self` and return a `Cow`. Making it similar to `Token::uninterpolate`. This avoids some more token tree cloning. * Avoid some token cloning in `filter_tokens_from_list`. Now the cloning only happens on some paths, instead of all paths. * Avoid some token tree cloning in decl macro parsing. By changing `into_trees` into `trees`. Some of the subsequent paths require explicit clones, but not all. * Avoid `into_trees` usage in rustfmt. Token tree cloning is only needed in one place. * Remove `Iterator` impl for `TokenTreeCursor`. This is surprising, but the new comment explains why. It's a logical conclusion in the drive to avoid `TokenTree` clones. `TokenTreeCursor` is now only used within `Parser`. It's still needed due to `replace_prev_and_rewind`. * Revert "don't uniquify regions when canonicalizing" This reverts commit 171f541. * Consider a goal as NOT changed if its response is identity modulo regions * Optimize `TokenKind::clone`. `TokenKind` would impl `Copy` if it weren't for `TokenKind::Interpolated`. This commit makes `clone` reflect that. * tests/ui/hello_world/main.rs: Remove FIXME The purpose of the test is to make sure that compiling hello world produces no compiler output. To properly test that, we need to run the entire compiler pipeline. We don't want the test to pass if codegen accidentally starts writing to stdout. So keep it as build-pass. * Turns out opaque types can have hidden types registered during mir validation * Remove transmute calls and caching for use paths * Revert "add tidy check that forbids issue ui test filenames" This reverts commit 13e2abf. Reverting because an MCP was requested and it turned out there was a lack of a consensus on what to do in this area. * Remove `constness` from `ParamEnv` * update tests, adding known-bug * Make `--print KIND=PATH` unstable rust-lang/rust#113780 should have gone through an MCP+FCP but wasn't, but instead of reverting the original PR, this PR just make that new option unstable. * bless clippy * docs(style-guide): don't flatten match arms with macro call * Change the description of `SUSPICIOUS_AUTO_TRAIT_IMPLS` * Introduce the `#[diagnostic]` attribute namespace Co-authored-by: est31 <est31@users.noreply.github.com> Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com> Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com> * imported src/doc/nomicon into main repository * imported src/tools/cargo into main repository * imported src/doc/reference into main repository * imported src/doc/book into main repository * imported src/doc/rust-by-example into main repository * imported library/stdarch into main repository * imported src/doc/rustc-dev-guide into main repository * imported src/doc/edition-guide into main repository * imported src/doc/embedded-book into main repository * imported library/backtrace into main repository * use crablang readme * imported src/tools/cargo into main repository * abandon submodules added a bash script that converts a project using gitsubmodules (ew) to a monorepo * use crab contrib --------- Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> Signed-off-by: David Wood <david@davidtw.co> Signed-off-by: DragonBillow <DragonBillow@outlook.com> Co-authored-by: Eric Mark Martin <ericmarkmartin@gmail.com> Co-authored-by: Yuri Astrakhan <YuriAstrakhan@gmail.com> Co-authored-by: bors <bors@rust-lang.org> Co-authored-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de> Co-authored-by: Simon Schöning <simon.schoening@rwth-aachen.de> Co-authored-by: Laurențiu Nicola <lnicola@dend.ro> Co-authored-by: Jonathan Pallant (Ferrous Systems) <jonathan.pallant@ferrous-systems.com> Co-authored-by: Mahdi Dibaiee <mdibaiee@pm.me> Co-authored-by: Zalathar <Zalathar@users.noreply.github.com> Co-authored-by: Ralf Jung <post@ralfj.de> Co-authored-by: Oli Scherer <git-spam-no-reply9815368754983@oli-obk.de> Co-authored-by: David Wood <david.wood@huawei.com> Co-authored-by: Guillaume Gomez <guillaume.gomez@huawei.com> Co-authored-by: Frank Steffahn <fdsteffahn@gmail.com> Co-authored-by: Eric Huss <eric@huss.org> Co-authored-by: Michael Goulet <michael@errs.io> Co-authored-by: lcnr <rust@lcnr.de> Co-authored-by: Matthias Krüger <matthias.krueger@famsik.de> Co-authored-by: Lukas Markeffsky <@> Co-authored-by: Martin Kröning <mkroening@posteo.net> Co-authored-by: Arlo Siemsen <arsiem@microsoft.com> Co-authored-by: bohan <bohan-zhang@foxmail.com> Co-authored-by: Tshepang Mbambo <tshepang@gmail.com> Co-authored-by: James Dietz <jamesthespeedy@gmail.com> Co-authored-by: Alex Zepeda <github@inferiorhumanorgans.com> Co-authored-by: DragonBillow <DragonBillow@outlook.com> Co-authored-by: Steven Trotter <stevetrot@gmail.com> Co-authored-by: Deadbeef <ent3rm4n@gmail.com> Co-authored-by: Martin Nordholts <enselic@gmail.com> Co-authored-by: clubby789 <jamie@hill-daniel.co.uk> Co-authored-by: Jakub Beránek <berykubik@gmail.com> Co-authored-by: yukang <moorekang@gmail.com> Co-authored-by: Amanieu d'Antras <amanieu@gmail.com> Co-authored-by: Nicholas Nethercote <n.nethercote@gmail.com> Co-authored-by: blyxyas <blyxyas@gmail.com> Co-authored-by: León Orell Valerian Liehr <me@fmease.dev> Co-authored-by: asquared31415 <34665709+asquared31415@users.noreply.github.com> Co-authored-by: Bruce Mitchener <bruce.mitchener@gmail.com> Co-authored-by: Santiago Pastorino <spastorino@gmail.com> Co-authored-by: MoskalykA <100430077+MoskalykA@users.noreply.github.com> Co-authored-by: Wesley Wiser <wesleywiser@microsoft.com> Co-authored-by: klensy <klensy@users.noreply.github.com> Co-authored-by: Trevor Gross <tmgross@umich.edu> Co-authored-by: Joel Dice <joel.dice@fermyon.com> Co-authored-by: Veera <sveera.2001@gmail.com> Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com> Co-authored-by: Jubilee Young <workingjubilee@gmail.com> Co-authored-by: Urgau <urgau@numericable.fr> Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com> Co-authored-by: Caleb Cartwright <caleb.cartwright@outlook.com> Co-authored-by: Oleksandr Babak <alexanderbabak@proton.me> Co-authored-by: Georg Semmler <github@weiznich.de> Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
…li-obk Stabilize `PATH` option for `--print KIND=PATH` This PR propose stabilizing the `PATH` option for `--print KIND=PATH`. This option was previously added in rust-lang#113780 (as insta-stable before being un-stablized in rust-lang#114139). Description of the `PATH` option: > A filepath may optionally be specified for each requested information kind, in the format `--print KIND=PATH`, just like for `--emit`. When a path is specified, information will be written there instead of to stdout. ------ Description of the original PR [\[link\]](rust-lang#113780 (comment)): > **Support --print KIND=PATH command line syntax** > > As is already done for `--emit KIND=PATH` and `-L KIND=PATH`. > > In the discussion of rust-lang#110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o path` to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`. > > I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](https://github.com/facebook/buck2/blob/d43cf3a51a31f00be2c2248e78271b0fef0452b4/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system. > > From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". https://github.com/rust-lang/cargo/blob/31eda6f7c360d9911f853b3014e057db61238f3e/src/cargo/core/compiler/build_context/target_info.rs#L242 ----- cc `@dtolnay` r? `@jackh726`
Stabilize `PATH` option for `--print KIND=PATH` This PR propose stabilizing the `PATH` option for `--print KIND=PATH`. This option was previously added in rust-lang/rust#113780 (as insta-stable before being un-stablized in rust-lang/rust#114139). Description of the `PATH` option: > A filepath may optionally be specified for each requested information kind, in the format `--print KIND=PATH`, just like for `--emit`. When a path is specified, information will be written there instead of to stdout. ------ Description of the original PR [\[link\]](rust-lang/rust#113780 (comment)): > **Support --print KIND=PATH command line syntax** > > As is already done for `--emit KIND=PATH` and `-L KIND=PATH`. > > In the discussion of rust-lang/rust#110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o path` to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`. > > I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](https://github.com/facebook/buck2/blob/d43cf3a51a31f00be2c2248e78271b0fef0452b4/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system. > > From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". https://github.com/rust-lang/cargo/blob/31eda6f7c360d9911f853b3014e057db61238f3e/src/cargo/core/compiler/build_context/target_info.rs#L242 ----- cc `@dtolnay` r? `@jackh726`
As is already done for
--emit KIND=PATH
and-L KIND=PATH
.In the discussion of #110785, it was pointed out that
--print KIND=PATH
is nicer than trying to apply the single global-o
path to--print
's output, because in general there can be multiple print requests within a single rustc invocation, and anyway-o
would already be used for a different meaning in the case oflink-args
andnative-static-libs
.I am interested in using
--print cfg=PATH
in Buck2. Currently Buck2 works around the lack of support for--print KIND=PATH
by indirecting through a Python wrapper script to redirect rustc's stdout into the location dictated by the build system.From skimming Cargo's usages of
--print
, it definitely seems like it would benefit from--print KIND=PATH
too. Currently it is working around the lack of this by inserting--crate-name=___ --print=crate-name
so that it can look for a line containing___
as a delimiter between the 2 other--print
informations it actually cares about. This is commented as a "HACK" and "abuse". https://github.com/rust-lang/cargo/blob/31eda6f7c360d9911f853b3014e057db61238f3e/src/cargo/core/compiler/build_context/target_info.rs#L242 (FYI @weihanglo as you dealt with this recently in rust-lang/cargo#11633.)Mentioning reviewers active in #110785: @fee1-dead @jyn514 @bjorn3