Skip to content
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

Merged
merged 14 commits into from
Jul 21, 2023
Merged

Conversation

dtolnay
Copy link
Member

@dtolnay dtolnay commented Jul 17, 2023

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 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 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

@rustbot
Copy link
Collaborator

rustbot commented Jul 17, 2023

r? @b-naber

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 17, 2023
sess.note_without_error(format!("native-static-libs: {}", &lib_args.join(" ")));

match out {
OutFileName::Real(_) => out.overwrite(&lib_args.join(" "), sess),
Copy link
Contributor

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?

Copy link
Member Author

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

compiler/rustc_driver_impl/src/lib.rs Outdated Show resolved Hide resolved
@dtolnay dtolnay force-pushed the printkindpath branch 2 times, most recently from 6e7346b to 4d5134f Compare July 19, 2023 22:22
@@ -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);
Copy link
Contributor

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(" ")?

Copy link
Contributor

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.

@b-naber
Copy link
Contributor

b-naber commented Jul 20, 2023

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

@bors
Copy link
Contributor

bors commented Jul 20, 2023

📌 Commit 4d5134f has been approved by b-naber

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 20, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 20, 2023
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`
@matthiaskrgr
Copy link
Member

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 20, 2023
@dtolnay
Copy link
Member Author

dtolnay commented Jul 20, 2023

@bors r=b-naber

@bors
Copy link
Contributor

bors commented Jul 20, 2023

📌 Commit c9b04d1bc862095e2799dfeaa1671d76021aceb6 has been approved by b-naber

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 20, 2023
@rust-log-analyzer

This comment has been minimized.

@dtolnay
Copy link
Member Author

dtolnay commented Jul 20, 2023

@bors r=b-naber

@bors
Copy link
Contributor

bors commented Jul 20, 2023

📌 Commit 11ae0af has been approved by b-naber

It is now in the queue for this repository.

bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 21, 2023
…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
@bors bors merged commit b1d1e99 into rust-lang:master Jul 21, 2023
@rustbot rustbot added this to the 1.73.0 milestone Jul 21, 2023
@dtolnay dtolnay deleted the printkindpath branch July 22, 2023 02:31
@Urgau
Copy link
Member

Urgau commented Jul 22, 2023

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
(sorry for the nomination if an FCP wasn't necessary)

@rustbot rustbot added the I-compiler-nominated Nominated for discussion during a compiler team meeting. label Jul 24, 2023
Urgau added a commit to Urgau/rust that referenced this pull request Jul 27, 2023
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.
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Jul 27, 2023
…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`
trvswgnr added a commit to crablang/crab that referenced this pull request Jul 28, 2023
* 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>
@apiraino
Copy link
Contributor

For the record, this was discussed in a T-compiler meeting on Zulip (suggested to stick to the protocol and go througn an MCP/FCP process before stabilizing a user-facing change).

@rustbot label -I-compiler-nominated

@rustbot rustbot removed the I-compiler-nominated Nominated for discussion during a compiler team meeting. label Aug 18, 2023
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
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants