c-variadic: fix implementation on `avr`
tracking issue: https://github.com/rust-lang/rust/issues/44930
cc target maintainer @Patryk27
I ran into multiple issues, and although with this PR and a little harness I can run the test with qemu on avr, the implementation is perhaps not ideal.
The problem we found is that on `avr` the `c_int/c_uint` types are `i16/u16`, and this was not handled in the c-variadic checks. Luckily there is a field in the target configuration that contains the targets `c_int_width`. However, this field is not actually used in `core` at all, there the 16-bit targets are just hardcoded.
https://github.com/rust-lang/rust/blob/1500f0f47f5fe8ddcd6528f6c6c031b210b4eac5/library/core/src/ffi/primitives.rs#L174-L185
Perhaps we should expose this like endianness and pointer width?
---
Finally there are some changes to the test to make it compile with `no_std`.
Suggest to bind `self.x` to `x` when field `x` may be in format string
Fixesrust-lang/rust#141350
I added the new test in the first commit, and committed the changes in the second one.
r? @fmease
cc @mejrs
Make `span_suggestions` always verbose
`span_suggestions` is to provide mutually exclusive suggestions. When it was introduced, we made its behavior be that if a single suggestion is given to it, we present the suggestion inline, otherwise in patch format. Changing this to make all of its uses be verbose, as that is closer in intent of output.
Reduce diagnostic type visibilities.
Most diagnostic types are only used within their own crate, and so have a `pub(crate)` visibility. We have some diagnostic types that are unnecessarily `pub`. This is bad because (a) information hiding, and (b) if a `pub(crate)` type becomes unused the compiler will warn but it won't warn for a `pub` type.
This commit eliminates unnecessary `pub` visibilities for some diagnostic types, and also some related things due to knock-on effects. (I found these types with some ad hoc use of `grep`.)
r? @Kivooeo
Handle nonnull pattern types in size skeleton
The original comment was correct, the size is always the same, but we have more information now. In theory there was an additional bug that would have allowed transmuting things of different sizes, but I don't see how that would have been actually doable as the `tail` types would always have differed.
fixesrust-lang/rust#155330
docs: Use `0b1` instead of `NonZero::MIN` in `NonZero::bit_width` doctests
This pull request updates the doctests for the `NonZero::bit_width` method. It replaces the use of the `NonZero::MIN` constant with an explicit binary literal `0b1`.
I think using `0b1` is more intuitive for illustrating the method's behavior than `NonZero::MIN`. Since other examples in the same doctests already use `0b111` and `0b1110`, this change brings the first example into alignment with the rest of the doctests.
I followed the existing pattern in the `NonZero::highest_one` and `NonZero::lowest_one` methods, which already use `0b1` in their doctests.
I also followed the convention of `uint::bit_width`, which uses the literal `0` instead of the `uint::MIN` constant in its doctests.
Disallow ZST allocations with `TypedArena`.
`DroplessArena::alloc` already disallows ZST allocation. `TypedArena::alloc` allows it but:
- (a) it's never used, and
- (b) writing to `NonNull::dangling()` seems dubious, even if the write is zero-sized.
This commit just changes it to panic on a ZST. This eliminates an untested code path, and we shouldn't be allocating ZSTs anyway. It also eliminates an unused ZST code path in `clear_last_chunk`.
r? @Nadrieril
Check diagnostic output in incremental `cpass` and `rpass` revisions
This allows compiler warnings to be annotated in `cpass` and `rpass` revisions, and verifies that no unexpected warnings occur.
---
My underlying motivation is that I want to be able to reduce or eliminate the confusing combination of `cfail` revisions with `//@ build-pass` directives, and replace them with a more straightforward `cpass` revision that also checks diagnostic output. That migration is not part of this PR.
Clean up `AttributeLintKind` and refactor diagnostic attribute linting
There was a fair amount of duplication here, and thanks to the proliferation of new diagnostic attributes these days, it was threatening to grow bigger.
Add `--quiet` flag to x.py and bootstrap to suppress output
This adds a `--quiet` flag to x.py and bootstrap to suppress some of the output when compiling Rust. It conflicts with `--verbose`, matching the behavior of `cargo` which does not allow `--verbose` and `--quiet`.
It works by passing quiet flags down to the underlying cargo, or LLVM build processes. Note that for LLVM, we only can suppress logs when we explicitly configure it with ninja. Otherwise we won't know what flag to pass along to whichever build system cmake decides to use.
This can be helpful with AI workloads in the Rust codebase to help shrink down the output to reduce token usage, which can help prevent context pollution and lower costs.
This patch was partially generated with Gemini, but I've reviewed the changes it made.
abort in core
Implements `core::process::abort_immediate` as a wrapper around `intrinsics::abort`.
- tracking issue: https://github.com/rust-lang/rust/issues/154601
(This PR used to also add `core::process::abort`, but that's been deferred to a later addition.)
clippy fix: non_canonical_clone_impl
Fixes:
```text
warning: non-canonical implementation of `clone` on a `Copy` type
--> library/core/src/clone.rs:682:33
|
682 | fn clone(&self) -> Self {
| _________________________________^
683 | | self
684 | | }
| |_________^ help: change this to: `{ *self }`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#non_canonical_clone_impl
= note: requested on the command line with `-W clippy::non-canonical-clone-impl`
warning: non-canonical implementation of `clone` on a `Copy` type
--> library/core/src/convert/mod.rs:935:35
|
935 | fn clone(&self) -> Infallible {
| ___________________________________^
936 | | match *self {}
937 | | }
| |_____^ help: change this to: `{ *self }`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#non_canonical_clone_impl
warning: non-canonical implementation of `clone` on a `Copy` type
--> library/core/src/marker.rs:856:29
|
856 | fn clone(&self) -> Self {
| _____________________________^
857 | | Self
858 | | }
| |_____^ help: change this to: `{ *self }`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#non_canonical_clone_impl
```
Add `--remap-path-scope` as unstable in rustdoc
This PR adds support for `rustc` `--remap-path-scope` flag in rustdoc as unstable.
`rustc` documentation for the flag is [here](https://doc.rust-lang.org/nightly/rustc/remap-source-paths.html#--remap-path-scope).
I added some complementary tests for `rustdoc`, no need I think to duplicate `rustc` UI tests.
resolve: Remove `inaccessible_ctor_reexport` resolver field
Collect the necessary information during error reporting instead of doing it on a good path from the core name resolution infra.
Also cleanup the related diagnostic code for struct constructors in general, see the individual commits.
This mitigates most of the harm brought by https://github.com/rust-lang/rust/pull/133477.
Emit fatal on invalid const args with nested defs
Fixed https://github.com/rust-lang/rust/issues/123629
Fixes https://github.com/rust-lang/rust/issues/154539
Invalid const args are rejected, so their surrounding HIR is not preserved. But nested defs inside them can still get created, leaving children lowered without a valid HIR parent and causing an ICE when later error handling walks HIR parents.
r? @BoxyUwU
Require that a `<_ as Try>::Residual` implement the `Residual` trait
The `Residual` trait was even more experimental than `Try`, but now that https://github.com/rust-lang/rfcs/pull/3721 is merged, I think it would make sense to require this. Technically it's not strictly required, but without it something working on `<T: Try>` might need an extra bound even to use a homogeneous try block with the same output type as `T::Output`. (Another `where` will of course be needed to return a *different* `impl Try` type still.)
cc https://github.com/rust-lang/rust/issues/154391
Most diagnostic types are only used within their own crate, and so have
a `pub(crate)` visibility. We have some diagnostic types that are
unnecessarily `pub`. This is bad because (a) information hiding, and (b)
if a `pub(crate)` type becomes unused the compiler will warn but it
won't warn for a `pub` type.
This commit eliminates unnecessary `pub` visibilities for some
diagnostic types, and also some related things due to knock-on effects.
(I found these types with some ad hoc use of `grep`.)
Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`
Currently, the following code compiles:
```rust
fn foo<T: Into<f32>>(_: T) {}
fn main() {
foo(1.0);
}
```
This is because the only `From<{float}>` impl for `f32` is currently `From<f32>`. However, once `impl From<f16> for f32` is added this is no longer the case. This would cause the float literal to fallback to `f64`, subsequently causing a type error as `f32` does not implement `From<f64>`. While this kind of change to type inference isn't technically a breaking change according to Rust's breaking change policy, the previous attempt to add `impl From<f16> for f32` was removed rust-lang/rust#123830 due to the large number of crates affected (by my count, there were root regressions in 42 crates and 52 GitHub repos, not including duplicates). This PR solves this problem by using `f32` as the fallback type for `{float}` when there is a trait predicate of `f32: From<{float}>`. This allows adding `impl From<f16> for f32` without affecting the code that currently compiles (such as the example above; this PR shouldn't affect what is possible on stable).
This PR also allows adding a future-incompatibility warning for the fallback to `f32` (currently implemented in the third commit) if the lang team wants one (allowing the `f32` fallback to be removed in the future); alternatively this could be expanded in the future into something more general like @tgross35 suggested in https://github.com/rust-lang/rust/issues/123831#issuecomment-2064728053. I think it would be also possible to disallow the `f32` fallback in a future edition.
As expected, a crater check showed [no non-spurious regressions](https://github.com/rust-lang/rust/pull/139087#issuecomment-2764732580).
For reference, I've based the implementation loosely on the existing `calculate_diverging_fallback`. This first commit adds the `f32` fallback, the second adds `impl From<f16> for f32`, and the third adds a FCW lint for the `f32` fallback. I think this falls under the types team, so
r? types
Fixes: rust-lang/rust#123831
Tracking issue: rust-lang/rust#116909
@rustbot label +T-lang +T-types +T-libs-api +F-f16_and_f128
To decide on whether a future-incompatibility warning is desired or otherwise (see above):
@rustbot label +I-lang-nominated
cc https://github.com/rust-lang/rust/issues/154024https://github.com/rust-lang/rust/issues/154005
This adds a `--quiet` flag to x.py and bootstrap to suppress some of the
output when compiling Rust. It conflicts with `--verbose`, matching the
behavior of `cargo` which does not allow `--verbose` and `--quiet`.
It works by passing quiet flags down to the underlying cargo, or LLVM
build processes. Note that for LLVM, we only can suppress logs when we
explicitly configure it with ninja. Otherwise we won't know what flag
to pass along to whichever build system cmake decides to use.
This can be helpful with AI workloads in the Rust codebase to help
shrink down the output to reduce token usage, which can help prevent
context pollution and lower costs.
This patch was partially generated with Gemini, but I've reviewed the
changes it made.
Reformat `top_level_options!` and `options!` macro declarations
These macros are already tricky, and having weird formatting doesn't help. Using a more regular style makes it easier to see where nesting begins and ends.
Extracted from https://github.com/rust-lang/rust/pull/154501 after the changes in https://github.com/rust-lang/rust/pull/149357 made rebasing very difficult.
There should be no change to compiler behaviour.
Stuart Cook