Make --print with path unstable
#114139
Merged
Make --print with path unstable
#114139
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-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.
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
|
@bors r+ |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 27, 2023
…kingjubilee Rollup of 4 pull requests Successful merges: - rust-lang#97571 (Add documentation on v0 symbol mangling.) - rust-lang#114122 (tests/ui/hello_world/main.rs: Remove FIXME (rust-lang#62277)) - rust-lang#114133 (Revert "add tidy check that forbids issue ui test filenames") - rust-lang#114139 (Make `--print` with path unstable) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 7, 2023
…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`
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Sep 12, 2023
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`
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.
#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
cc @dtolnay