Remove usages of `QueryNormalizer` in the compiler
I want to get rid of the `QueryNormalizer`, possibly changing it to be special cased just for normalizing erasing regions, or perhaps adapting `normalize_erasing_regions` to use the assoc type normalizer if caching is sufficient and removing it altogther.
This removes the last two usages of `.query_normalize` in the *compiler*. There are a few usages left in rustdoc and clippy, which exist only because the query normalizer is more resilient to errors and non-well-formed alias types. I will remove those next.
r? lcnr or reassign
For E0223, suggest associated functions that are similar to the path, even if the base type has multiple inherent impl blocks.
Currently, the "help: there is an associated function with a similar name `from_utf8`" suggestion for `String::from::utf8` is only given if `String` has exactly one inherent `impl` item. This PR makes the suggestion be emitted even if the base type has multiple inherent `impl` items.
Example:
```rust
struct Foo;
impl Foo {
fn bar_baz() {}
}
impl Foo {} // load-bearing
fn main() {
Foo::bar::baz;
}
```
Nightly/stable output:
```rust
error[E0223]: ambiguous associated type
--> f.rs:7:5
|
7 | Foo::bar::baz;
| ^^^^^^^^
|
help: if there were a trait named `Example` with associated type `bar` implemented for `Foo`, you could use the fully-qualified path
|
7 | <Foo as Example>::bar::baz;
| ~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0223`.
```
Output with this PR, or without the load-bearing empty impl on nightly/stable:
```rust
error[E0223]: ambiguous associated type
--> f.rs:7:5
|
7 | Foo::bar::baz;
| ^^^^^^^^
|
help: there is an associated function with a similar name: `bar_baz`
|
7 | Foo::bar_baz;
| ~~~~~~~
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0223`.
```
Ideally, this suggestion would also work for non-ADT types like ~~`str::char::indices`~~ (edit: latest commit makes this work with primitives) or `<dyn Any>::downcast::mut_unchecked`, but that seemed to be a harder change.
`@rustbot` label +A-diagnostics
rustdoc-json: Rename `Path::name` to `path`, and give it the path again.
Closes: #135600.
Reverts #134880 (Effectively, but not actually, as the `FORMAT_VERSION` needs to be bumped, changed docs/tests). CC `@AS1100K.`
Also CC `@obi1kenobi` `@LukeMathWalker`
Still needs before being merge-ready:
- [x] Tests for cross-crate paths
- [x] (Maybe) Document what the field does.
- [x] Decide if the field rename is good (https://github.com/rust-lang/rust/pull/135799#issuecomment-2605937831)
- [ ] Squash commits.
r? `@GuillaumeGomez`
Add NuttX support for AArch64 and ARMv7-A targets
This patch adds tier 3 support for AArch64 and ARMv7-A targets in NuttX, including:
- AArch64 target: aarch64-unknown-nuttx
- ARMv7-A target: armv7a-nuttx-eabi, armv7a-nuttx-eabihf
- Thumbv7-A target: thumbv7a-nuttx-eabi, thumbv7a-nuttx-eabihf
remove pointless allowed_through_unstable_modules on TryFromSliceError
This got added in https://github.com/rust-lang/rust/pull/132482 but the PR does not explain why. `@lukas-code` do you still remember? Also Cc `@Noratrieb` as reviewer of that PR.
If I understand the issue description correctly, all paths under which this type is exported are stable now: `core::array::TryFromSliceError` and `std::array::TryFromSliceError`. If that is the case, we shouldn't have the attribute; it's a terrible hack that should only be used when needed to maintain backward compatibility. Getting some historic information right is IMO *not* sufficient justification to risk accidentally exposing this type via more unstable paths today or in the future.
Add extensive set of drop order tests
On lang, we've recently been discussing the drop order with respect to `let` chains apropos of how we shortened temporary lifetimes in Rust 2024 and how we may shorten them further in the future.
Here we add an extensive set of tests that demonstrate the drop order in the cases that interest us.
Regarding the let chains stabilization prompting this analysis, see:
- https://github.com/rust-lang/rust/pull/132833
r? ghost
cc `@ehuss` `@dingxiangfei2009` `@nikomatsakis`
By removing all methods from this struct and treating it as a collection of
data fields, we make it easier for a future PR to store that data in a query
result, without having to move all of its methods into `rustc_middle`.
This dedicated type seemed like a good idea at the time, but if we want to
store this information in a query result then a plainer data type is more
convenient.
Using `SmallVec` here was fine when it was a module-private detail, but if we
want to pass these terms across query boundaries then it's not worth the extra
hassle.
Replacing a method call with direct field access is slightly simpler.
Using the name `counter_terms` is more consistent with other code that tries to
maintain a distinction between (physical) "counters" and "expressions".
This reflects the fact that we can't compute meaningful info for a function
that wasn't instrumented and therefore doesn't have `function_coverage_info`.
These types are unlikely to ever contain type information in the foreseeable
future, so excluding them from TypeFoldable/TypeVisitable avoids some unhelpful
derive boilerplate.
Rollup of 7 pull requests
Successful merges:
- #135366 (Enable `unreachable_pub` lint in `test` and `proc_macro` crates)
- #135638 (Make it possible to build GCC on CI)
- #135648 (support wasm inline assembly in `naked_asm!`)
- #135827 (CI: free disk with in-tree script instead of GitHub Action)
- #135855 (Only assert the `Parser` size on specific arches)
- #135878 (ci: use 8 core arm runner for dist-aarch64-linux)
- #135905 (Enable kernel sanitizers for aarch64-unknown-none-softfloat)
r? `@ghost`
`@rustbot` modify labels: rollup
```
error[E0432]: unresolved import `some_novel_crate`
--> file.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
```
On resolve errors where there might be a missing crate, mention `cargo add foo`:
```
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `nope`
--> $DIR/conflicting-impl-with-err.rs:4:11
|
LL | impl From<nope::Thing> for Error {
| ^^^^ use of unresolved module or unlinked crate `nope`
|
= help: if you wanted to use a crate named `nope`, use `cargo add nope` to add it to your `Cargo.toml`
```
We were previously printing the full type on the "this expression has type" label.
```
error[E0308]: mismatched types
--> $DIR/secondary-label-with-long-type.rs:8:9
|
LL | let () = x;
| ^^ - this expression has type `((..., ..., ..., ...), ..., ..., ...)`
| |
| expected `((..., ..., ..., ...), ..., ..., ...)`, found `()`
|
= note: expected tuple `((..., ..., ..., ...), ..., ..., ...)`
found unit type `()`
= note: the full type name has been written to '$TEST_BUILD_DIR/diagnostic-width/secondary-label-with-long-type/secondary-label-with-long-type.long-type-3987761834644699448.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Reported in a comment of #135919.
Skip `if-let-rescope` lint unless requested by migration
Tracked by #124085
Related to https://github.com/rust-lang/rust/pull/131984#issuecomment-2448329667
Given that `if-let-rescope` is a lint to be enabled globally by an edition migration, there is no point in extracting the precise lint level on the HIR expression. This mitigates the performance regression discovered by the earlier perf-run.
cc `@Kobzol` `@rylev` `@traviscross` I propose a `rust-timer` run to measure how much performance that we can recover from the mitigation. 🙇
Enable kernel sanitizers for aarch64-unknown-none-softfloat
We want kernels to be able to use this bare metal target, so let's enable the sanitizers that kernels want to use.
cc ```@rcvalle``` ```@ojeda``` ```@maurer```
Only assert the `Parser` size on specific arches
The size of this struct depends on the alignment of `u128`, for example
powerpc64le and s390x have align-8 and end up with only 280 bytes. Our
64-bit tier-1 arches are the same though, so let's just assert on those.
r? nnethercote
support wasm inline assembly in `naked_asm!`
fixes https://github.com/rust-lang/rust/issues/135518
Webassembly was overlooked previously, but now `naked_asm!` and `#[naked]` functions work on the webassembly targets.
Or, they almost do right now. I guess this is no surprise, but the `wasm32-unknown-unknown` target causes me some trouble. I'll add some inline comments with more details.
r? ```````@bjorn3```````
cc ```````@daxpedda,``````` ```````@tgross35```````
Make it possible to build GCC on CI
This is the first step towards eventually enabling download of precompiled GCC from our CI.
Currently, we prebuild `libgccjit` on CI and cache it in Docker. This PR improves the bootstrap GCC step to make it work on CI, and also to make it faster by using sccache. After this change, an actual build on CI should take only 2-3 minutes.
Note that this PR does not yet remove the `build-gccjit.sh` script and replace it with the bootstrap step, I'll leave that to a follow-up PR.
The added `flex` package and the ZSTD library fix were needed to make GCC build on CI.
CC ``````@GuillaumeGomez``````
r? ``````@onur-ozkan``````
Enable `unreachable_pub` lint in `test` and `proc_macro` crates
This PR enables the [`unreachable_pub`](https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unreachable-pub) lint as warn in the `test` and `proc_macro` crates.
The diff was mostly generated with `./x.py fix --stage 1 library/proc_macro/ -- --broken-code`, as well as manual edits for code in macros and in tests.
Continuation of #134286
r? libs
On lang, we've recently been discussing the drop order with respect to
`let` chains apropos of how we shortened temporary lifetimes in Rust
2024 and how we may shorten them further in the future.
Here we add an extensive set of tests that demonstrate the drop order
in the cases that interest us.
Allow `arena_cache` queries to return `Option<&'tcx T>`
Currently, `arena_cache` queries always have to return `&'tcx T`[^deref]. This means that if an arena-cached query wants to return an optional value, it has to return `&'tcx Option<T>`, which has a few negative consequences:
- It goes against normal Rust style, where `Option<&T>` is preferred over `&Option<T>`.
- Callers that actually want an `Option<&T>` have to manually call `.as_ref()` on the query result.
- When the query result is `None`, a full-sized `Option<T>` still needs to be stored in the arena.
This PR solves that problem by introducing a helper trait `ArenaCached` that is implemented for both `&T` and `Option<&T>`, and takes care of bridging between the provided type, the arena-allocated type, and the declared query return type.
---
To demonstrate that this works, I have converted the two existing arena-cached queries that currently return `&Option<T>`: `mir_coroutine_witnesses` and `diagnostic_hir_wf_check`. Only the query declarations need to be modified; existing providers and callers continue to work with the new query return type.
(My real goal is to apply this to `coverage_ids_info`, which will return Option as of #135873, but that PR hasn't landed yet.)
[^deref]: Technically they could return other types that implement `Deref`, but it's hard to imagine this working well with anything other than `&T`.
rustc_codegen_llvm: remove outdated asm-to-obj codegen note
Remove comment about missing integrated assembler handling, which was removed in commit 02840ca.
Get rid of RunCompiler
The various `set_*` methods that have been removed can be replaced by setting the respective fields in the `Callbacks::config` implementation. `set_using_internal_features` was often forgotten and it's equivalent is now done automatically.
handle global trait bounds defining assoc types
This also fixes the compare-mode for
- tests/ui/coherence/coherent-due-to-fulfill.rs
- tests/ui/codegen/mono-impossible-2.rs
- tests/ui/trivial-bounds/trivial-bounds-inconsistent-projection.rs
- tests/ui/nll/issue-61320-normalize.rs
I first considered the alternative to always prefer where-bounds during normalization, regardless of how the trait goal has been proven by changing `fn merge_candidates` instead. ecda83b30f/compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs (L785)
This approach is more restrictive than behavior of the old solver to avoid mismatches between trait and normalization goals. This may be breaking in case the where-bound adds unnecessary region constraints and we currently don't ever try to normalize an associated type. I would like to detect these cases and change the approach to exactly match the old solver if required. I want to minimize cases where attempting to normalize in more places causes code to break.
r? `@compiler-errors`
Add missing check for async body when suggesting await on futures.
Currently the compiler suggests adding `.await` to resolve some type conflicts without checking if the conflict happens in an async context. This can lead to the compiler suggesting `.await` in function signatures where it is invalid. Example:
```rs
trait A {
fn a() -> impl Future<Output = ()>;
}
struct B;
impl A for B {
fn a() -> impl Future<Output = impl Future<Output = ()>> {
async { async { () } }
}
}
```
```
error[E0271]: expected `impl Future<Output = impl Future<Output = ()>>` to be a future that resolves to `()`, but it resolves to `impl Future<Output = ()>`
--> bug.rs:6:15
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found future
|
note: calling an async function returns a future
--> bug.rs:6:15
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `A::{synthetic#0}`
--> bug.rs:2:27
|
2 | fn a() -> impl Future<Output = ()>;
| ^^^^^^^^^^^ required by this bound in `A::{synthetic#0}`
help: consider `await`ing on the `Future`
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>>.await {
| ++++++
```
The documentation of suggest_await_on_expect_found (`compiler/rustc_trait_selection/src/error_reporting/infer/suggest.rs:156`) even mentions such a check but does not actually implement it.
This PR adds that check to ensure `.await` is only suggested within async blocks.
There were 3 unit tests whose expected output needed to be changed because they had the suggestion outside of async. One of them (`tests/ui/async-await/dont-suggest-missing-await.rs`) actually tests that exact problem but expects it to be present.
Thanks to `@llenck` for initially noticing the bug and helping with fixing it
Implement `ByteStr` and `ByteString` types
Approved ACP: https://github.com/rust-lang/libs-team/issues/502
Tracking issue: https://github.com/rust-lang/rust/issues/134915
These types represent human-readable strings that are conventionally,
but not always, UTF-8. The `Debug` impl prints non-UTF-8 bytes using
escape sequences, and the `Display` impl uses the Unicode replacement
character.
This is a minimal implementation of these types and associated trait
impls. It does not add any helper methods to other types such as `[u8]`
or `Vec<u8>`.
I've omitted a few implementations of `AsRef`, `AsMut`, and `Borrow`,
when those would be the second implementation for a type (counting the
`T` impl), to avoid potential inference failures. We can attempt to add
more impls later in standalone commits, and run them through crater.
In addition to the `bstr` feature, I've added a `bstr_internals` feature
for APIs provided by `core` for use by `alloc` but not currently
intended for stabilization.
This API and its implementation are based *heavily* on the `bstr` crate
by Andrew Gallant (`@BurntSushi).`
r? `@BurntSushi`
- Convert `run-pass` to `check-pass`, the test is about closure
inference based on expected type, does not need to run-pass.
- Dropped unnecessary ignores.
