Replace `pthread_set_name_np` with `pthread_setname_np` for NuttX in the `set_name` function,
this change aligns the implementation with the correct API available on NuttX
This patch ensures thread naming works correctly on NuttX platforms.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Rollup of 8 pull requests
Successful merges:
- #133605 (Add extensive set of drop order tests)
- #135489 (remove pointless allowed_through_unstable_modules on TryFromSliceError)
- #135757 (Add NuttX support for AArch64 and ARMv7-A targets)
- #135799 (rustdoc-json: Rename `Path::name` to `path`, and give it the path again.)
- #135865 (For E0223, suggest associated functions that are similar to the path, even if the base type has multiple inherent impl blocks.)
- #135890 (Implement `VecDeque::pop_front_if` & `VecDeque::pop_back_if`)
- #135914 (Remove usages of `QueryNormalizer` in the compiler)
- #135936 (fix reify-intrinsic test)
r? `@ghost`
`@rustbot` modify labels: rollup
fix reify-intrinsic test
These are no longer `extern "rust-intrinsic"` functions so it no longer makes sense to try to cast them to that type.
r? `@oli-obk`
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`
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
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`
Rollup of 9 pull requests
Successful merges:
- #134746 (Don't ICE in coerce when autoderef fails to structurally normalize non-WF type in new solver)
- #135552 ([AIX] Lint on structs that have a different alignment in AIX's C ABI)
- #135779 (CI: free disk on linux arm runner)
- #135790 (Update windows-gnu targets to set `DebuginfoKind::DWARF`)
- #135879 (fix outdated file path ref in llvm)
- #135883 (Remove erroneous `unsafe` in `BTreeSet::upper_bound_mut`)
- #135884 (remove implied end of slice)
- #135887 (improvements on `build_steps::test` implementation)
- #135898 (rustdoc-json-types: Finalize dyn compatibility renaming)
r? `@ghost`
`@rustbot` modify labels: rollup
Refactor `fmt::Display` impls in rustdoc
This PR does a couple of things, with the intention of cleaning up and streamlining some of the `fmt::Display` impls in rustdoc:
1. Use the unstable [`fmt::from_fn`](https://github.com/rust-lang/rust/issues/117729) instead of open-coding it.
2. ~~Replace bespoke implementations of `Itertools::format` with the method itself.~~
4. Some more minor cleanups - DRY, remove unnecessary calls to `Symbol::as_str()`, replace some `format!()` calls with lazier options
The changes are mostly cosmetic but some of them might have a slight positive effect on performance.
rustdoc-json-types: Finalize dyn compatibility renaming
Followup to #131595.
Part of #130852.
Inspired by #135858 (does the same thing but for the rustdoc-types docs).
r? ````@fmease````
Update windows-gnu targets to set `DebuginfoKind::DWARF`
These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo.
This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers.
cc ````@mati865```` since you mentioned this in #135739
cc ````@davidtwco```` for split-dwarf
[AIX] Lint on structs that have a different alignment in AIX's C ABI
This PR adds a linting diagnostic on AIX for repr(C) structs that are required to follow
the power alignment rule. A repr(C) struct needs to follow the power alignment rule if
the struct:
- Has a floating-point data type (greater than 4-bytes) as its first member, or
- The first member of the struct is an aggregate, whose recursively first member is a
floating-point data type (greater than 4-bytes).
The power alignment rule for eligible structs is currently unimplemented, so a linting
diagnostic is produced when such a struct is encountered.
tests: Port `jobserver-error` to rmake.rs
Part of #121876.
This PR ports `tests/run-make/jobserver-error` to rmake.rs, and is basically #128789 slightly adjusted.
The complexity involved here is mostly how to get `/dev/null/` piping to fd 3 working with std `Command`, whereas with a shell this is much easier (as is evident with the `Makefile` version).
Supersedes #128789.
This PR is co-authored with `@Oneirical` and `@coolreader18.`
try-job: aarch64-gnu
try-job: i686-gnu-1
try-job: x86_64-gnu-debug
try-job: x86_64-gnu-llvm-18-1
