Add platform support docs & maintainers for *-windows-msvc
Thanks to `@ChrisDenton,` `@dpaoliello,` `@lambdageek` and `@sivadeilra` for agreeing to be target maintainers!
cc rust-lang/rust#113739
compiletest: Clarify that `--no-capture` is needed with `--verbose`
Confusingly, this does not make compile test print what command is used to run a ui test:
./x test tests/ui/panics/abort-on-panic.rs --verbose
It is also necessary to pass `--no-capture`, like this:
./x test tests/ui/panics/abort-on-panic.rs --verbose --no-capture
Then you will see prints like this:
executing cd "/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next" && \
RUSTC="/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" \
RUST_TEST_THREADS="32" \
"/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next/a"
Add a hint in the code for this that would have helped me figure this out.
(See https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/compiltest.20show.20rustc.20commands.3F for some more context.)
Remove "intermittent" wording from `ReadDir`
`ReadDir` claims that `next` will return an error "if there’s some sort of intermittent IO error during iteration". I'm really not sure what this was intended to mean but the implementations will simply return all OS errors encountered during iteration to the user. What else can they do?
This is technically a change in the documented API but seeing as how it doesn't bear any relationship with the implementation I don't think it needs a libs-api fcp.
Delay replacing escaping bound vars in `FindParamInClause`
By uplifting the `BoundVarReplacer`, which is used by (e.g.) normalization to replace escaping bound vars that are encountered when folding binders, we can use a similar strategy to delay the instantiation of a binder's contents in the `FindParamInClause` used by the new trait solver.
This should alleviate the recently added requirement that `Binder<T>: TypeVisitable` only if `T: TypeFoldable`, which was previously required b/c we were calling `enter_forall` so that we could structurally normalize aliases that we found within the predicates of a param-env clause.
r? lcnr
doc: mention that intrinsics should not be called in user code
Intrinsic functions declared in `std::intrinsics` are an implementation detail and should not be called directly by the user. The compiler explicitly warns against their use in user code:
```
warning: the feature `core_intrinsics` is internal to the compiler or standard library
--> src/lib.rs:1:12
|
1 | #![feature(core_intrinsics)]
| ^^^^^^^^^^^^^^^
|
= note: using it is strongly discouraged
= note: `#[warn(internal_features)]` on by default
```
[**Playground link**]
This PR documents what the compiler warning says: these intrinsics should not be used in user code.
[**Playground link**]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1c893b0698291f550bbdde0151fd221b
Pre-install JS dependencies in tidy Dockerfile
Also fixes passing `TIDY_PRINT_DIFF` to tidy, which has been passed to `npm install` rather than to tidy after the latest change here.
r? `@GuillaumeGomez`
Fixes: https://github.com/rust-lang/rust/issues/142433
Don't hardcode the intrinsic return types twice in the compiler
We already manually check intrinsic types in intrinsicck so we don't need to do it in the interpreter
Rework how the disallowed qualifier in function type diagnostics are generated
This pull request fixes two independent issues:
1. When qualifiers of a function type ptr are in the wrong order and one of them is async/const (not permitted on function types), the diagnostic suggests removing the incorrect qualifier. Fixes https://github.com/rust-lang/rust/issues/142268, which is an issue created by https://github.com/rust-lang/rust/pull/133151. This is fixed by moving the check into `parse_fn_front_matter`, where better span information is available to generate the right suggestions.
2. When qualifiers of a function type ptr are in the wrong order and one of them is async/const (not permitted on function types), `cargo fix` crashes because "cannot replace slice of data that was already replaced". This is fixed by not generating a suggestion for the "wrong order" diagnostic if the "disallowed qualifier" diagnostic is triggered.
There is a commit with failing tests so the test diff is clearer
r? `@jdonszelmann`
tests: Minicore `extern "gpu-kernel"` feature test
Explicitly cross-build it for GPU targets and check it errors on hosts. A relatively minor cleanup from my other ABI-related PRs that I got tired of rebasing.
builtin dyn impl no guide inference
cc https://github.com/rust-lang/rust/pull/141347
we can already slightly restrict this behavior in the old solver, so why not do so. Needs crater and an FCP.
r? `@compiler-errors`
Allow initializing logger with additional tracing Layer
This PR adds functions to the `rustc_log` and `rustc_driver_impl` crates to allow initializing the logger with an additional `tracing_subscriber::Layer`. This will be used in Miri to save trace events to file using e.g. [`tracing-chrome`](https://github.com/thoren-d/tracing-chrome)'s or [`tracing-tracy`](https://github.com/nagisa/rust_tracy_client)'s `Layer`s.
Additional context on the choice of signature can be found in [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Adding.20a.20dependency.20to.20Miri.20that.20depends.20on.20a.20rustc.20dep/near/515707776).
I re-exported `tracing_subscriber::{Layer, Registry};` from `rustc_log` so that `rustc_driver_impl` can use them in the function signature without depending on `tracing_subscriber` directly. I did this to avoid copy-pasting the dependency line with all of the enabled features from the `rustc_log` to the `rustc_driver_impl`'s Cargo.toml, which would have possibly led to redundancies and inconsistencies.
r? `@RalfJung`
Build rustc with assertions in `dist-alt` jobs
Revival of https://github.com/rust-lang/rust/pull/131077, to check CI times now that we don't do PGO/BOLT anymore on Linux `-alt` builds.
r? `@ghost`
try-job: dist-x86_64-msvc-alt
try-job: dist-x86_64-linux-alt
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> $DIR/missing-derive-2.rs:22:7
|
LL | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Deserialize` and `Serialize` accept the similarly named `serde` attribute
|
LL | #[serde(untagged)]
| +
error: cannot find attribute `serde` in this scope
--> $DIR/missing-derive-2.rs:16:7
|
LL | #[serde(untagged)]
| ^^^^^
|
note: `serde` is imported here, but it is a crate, not an attribute
--> $DIR/missing-derive-2.rs:5:1
|
LL | extern crate serde;
| ^^^^^^^^^^^^^^^^^^^
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
LL + #[derive(Serialize, Deserialize)]
LL | enum B {
|
```
Partially address #47608. This PR doesn't find [macros that haven't yet been imported by name](https://github.com/rust-lang/rust/pull/109278/commits/af945cb86e03b44a4b6dc4d54ec1424b00a2349e).
Confusingly, this does not make compile test print what command is used
to run a ui test:
./x test tests/ui/panics/abort-on-panic.rs --verbose
It is also necessary to pass `--no-capture`, like this:
./x test tests/ui/panics/abort-on-panic.rs --verbose --no-capture
Now you will see prints like this:
executing cd "/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next" && \
RUSTC="/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" \
RUST_TEST_THREADS="32" \
"/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next/a"
Add a hint in the code for this that would have helped me figure this out.
Intrinsic functions declared in `std::intrinsics` are an implementation
detail and should not be called directly by the user. The compiler
explicitly warns against their use in user code:
```
warning: the feature `core_intrinsics` is internal to the compiler or standard library
--> src/lib.rs:1:12
|
1 | #![feature(core_intrinsics)]
| ^^^^^^^^^^^^^^^
|
= note: using it is strongly discouraged
= note: `#[warn(internal_features)]` on by default
```
[**Playground link**]
This PR documents what the compiler warning says: these intrinsics should
not be called outside the standard library.
[**Playground link**]: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1c893b0698291f550bbdde0151fd221b
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from
`libc`.
I don't really trust callgrind when it says I've turn 81 billion
instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20
times
without incr" method and it went from 0.31s-0.45s to 0.25s
constistently.
(Profiled, and "benchmarked") on tokio.
What I can get behind is via `strlen_on_c_strings` changing from 31
million instructions into 76k. 🎉🥳
changelog: [`strlen_on_c_strings`]: Optimize it by 99.75%
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#138016 (Added `Clone` implementation for `ChunkBy`)
- rust-lang/rust#141162 (refactor `AttributeGate` and `rustc_attr!` to emit notes during feature checking)
- rust-lang/rust#141474 (Add `ParseMode::Diagnostic` and fix multiline spans in diagnostic attribute lints)
- rust-lang/rust#141947 (Specify that "option-like" enums must be `#[repr(Rust)]` to be ABI-compatible with their non-1ZST field.)
- rust-lang/rust#142252 (Improve clarity of `core::sync::atomic` docs about "Considerations" in regards to CAS operations)
- rust-lang/rust#142337 (miri: add flag to suppress float non-determinism)
r? `@ghost`
`@rustbot` modify labels: rollup
