Add `&pin (mut|const) T` type position sugar
This adds parser support for `&pin mut T` and `&pin const T` references. These are desugared to `Pin<&mut T>` and `Pin<&T>` in the AST lowering phases.
This PR currently includes #130526 since that one is in the commit queue. Only the most recent commits (bd450027eb4a94b814a7dd9c0fa29102e6361149 and following) are new.
Tracking:
- #130494
r? `@compiler-errors`
Remove `'apostrophes'` from `rustc_parse_format`
The rest of the compiler uses \`grave accents\`, while `rustc_parse_format` uses \`'apostrophes.'\`
Also makes the crate compile as a stand-alone:
```
~/rust/compiler/rustc_parse_format $ cargo check
Compiling rustc_index_macros v0.0.0 (/home/lieselotte/rust/compiler/rustc_index_macros)
error[E0277]: `syn::Lit` doesn't implement `Debug`
--> compiler/rustc_index_macros/src/newtype.rs:52:57
|
52 | panic!("Specified multiple max: {old:?}");
| ^^^^^^^ `syn::Lit` cannot be formatted using `{:?}` because it doesn't implement `Debug`
|
= help: the trait `Debug` is not implemented for `syn::Lit`
= note: this error originates in the macro `$crate::const_format_args` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0277]: `syn::Lit` doesn't implement `Debug`
--> compiler/rustc_index_macros/src/newtype.rs:64:74
|
64 | panic!("Specified multiple debug format options: {old:?}");
| ^^^^^^^ `syn::Lit` cannot be formatted using `{:?}` because it doesn't implement `Debug`
|
= help: the trait `Debug` is not implemented for `syn::Lit`
= note: this error originates in the macro `$crate::const_format_args` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0277`.
error: could not compile `rustc_index_macros` (lib) due to 2 previous errors
```
`@rustbot` label +A-diagnostics
Suppress import errors for traits that couldve applied for method lookup error
Self-explanatory. I hit this quite often when refactoring in rustc, so even though this isn't really showing up as significant in the UI test suite, it probably will matter more for multi-module projects.
Fix up-to-date checking for run-make tests
This special case in `output_base_dir` had the unfortunate side-effect of causing all run-make tests to share the same `stamp` file. So as soon as any one of them succeeded, all of the failed tests would be incorrectly considered up-to-date and would no longer run in subsequent test invocations.
Fixes#129971.
r? jieyouxu
Update lint message for ABI not supported
Tracking issue: #130260
As requested in https://github.com/rust-lang/rust/pull/128784#pullrequestreview-2364026550 I updated the error message.
I could also change it to be the same message as if it was a hard error on a normal function:
> "`{abi}` is not a supported ABI for the current target"
Or would that get confusing when people try to google the error message?
r? compiler-errors
Fix bug where `option_env!` would return `None` when env var is present but not valid Unicode
Fixes#122669 by making `option_env!` emit an error when the value of the environment variable is not valid Unicode.
Autodiff Upstreaming - enzyme frontend
This is an upstream PR for the `autodiff` rustc_builtin_macro that is part of the autodiff feature.
For the full implementation, see: https://github.com/rust-lang/rust/pull/129175
**Content:**
It contains a new `#[autodiff(<args>)]` rustc_builtin_macro, as well as a `#[rustc_autodiff]` builtin attribute.
The autodiff macro is applied on function `f` and will expand to a second function `df` (name given by user).
It will add a dummy body to `df` to make sure it type-checks. The body will later be replaced by enzyme on llvm-ir level,
we therefore don't really care about the content. Most of the changes (700 from 1.2k) are in `compiler/rustc_builtin_macros/src/autodiff.rs`, which expand the macro. Nothing except expansion is implemented for now.
I have a fallback implementation for relevant functions in case that rustc should be build without autodiff support. The default for now will be off, although we want to flip it later (once everything landed) to on for nightly. For the sake of CI, I have flipped the defaults, I'll revert this before merging.
**Dummy function Body:**
The first line is an `inline_asm` nop to make inlining less likely (I have additional checks to prevent this in the middle end of rustc. If `f` gets inlined too early, we can't pass it to enzyme and thus can't differentiate it.
If `df` gets inlined too early, the call site will just compute this dummy code instead of the derivatives, a correctness issue. The following black_box lines make sure that none of the input arguments is getting optimized away before we replace the body.
**Motivation:**
The user facing autodiff macro can verify the user input. Then I write it as args to the rustc_attribute, so from here on I can know that these values should be sensible. A rustc_attribute also turned out to be quite nice to attach this information to the corresponding function and carry it till the backend.
This is also just an experiment, I expect to adjust the user facing autodiff macro based on user feedback, to improve usability.
As a simple example of what this will do, we can see this expansion:
From:
```
#[autodiff(df, Reverse, Duplicated, Const, Active)]
pub fn f1(x: &[f64], y: f64) -> f64 {
unimplemented!()
}
```
to
```
#[rustc_autodiff]
#[inline(never)]
pub fn f1(x: &[f64], y: f64) -> f64 {
::core::panicking::panic("not implemented")
}
#[rustc_autodiff(Reverse, Duplicated, Const, Active,)]
#[inline(never)]
pub fn df(x: &[f64], dx: &mut [f64], y: f64, dret: f64) -> f64 {
unsafe { asm!("NOP"); };
::core::hint::black_box(f1(x, y));
::core::hint::black_box((dx, dret));
::core::hint::black_box(f1(x, y))
}
```
I will add a few more tests once I figured out why rustc rebuilds every time I touch a test.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
try-job: dist-x86_64-msvc
Special treatment empty tuple when suggest adding a string literal in format macro.
For example:
```rust
let s = "123";
println!({}, "sss", s);
```
Suggest:
`println!("{:?} {} {}", {}, "sss", s);`
fixes#130170
Update precondition tests (especially for zero-size access to null)
I don't much like the current way I've updated the precondition check helpers, but I couldn't come up with anything better. Ideas welcome.
I've organized `tests/ui/precondition-checks` mostly with one file per function that has `assert_unsafe_precondition` in it, with revisions that check each precondition. The important new test is `tests/ui/precondition-checks/zero-size-null.rs`.
Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly
Currently `clobber_abi` in Arm64EC inline assembly is implemented using `InlineAsmClobberAbi::AArch64NoX18`, but broken since it attempts to clobber registers that cannot be used in Arm64EC: https://godbolt.org/z/r3PTrGz5r
```
error: cannot use register `x13`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
--> <source>:6:14
|
6 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x14`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
--> <source>:6:14
|
6 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
<omitted the same errors for v16-v31>
```
Additionally, this disallows SVE-related registers per https://github.com/rust-lang/rust/pull/131332#issuecomment-2401189142.
cc ``@dpaoliello``
r? ``@Amanieu``
``@rustbot`` label O-windows O-AArch64 +A-inline-assembly
This special case in `output_base_dir` had the unfortunate side-effect of
causing all run-make tests to share the same `stamp` file. So as soon as any
one of them succeeded, all of the failed tests would be considered up-to-date
and would no longer run in subsequent test invocations.
Remap path prefix in the panic message of `tests/ui/meta/revision-bad.rs`
Otherwise `error-pattern` on the test run stderr can incorrectly match if the paths in panic backtrace has a matching substring (like if we look for `bar` in the error pattern, but the username is `baron`).
Tested locally by checking run output `./x test .\tests\ui\meta\revision-bad.rs -- -- --nocapture`:
```
--- stderr -------------------------------
thread 'main' panicked at remapped\meta\revision-bad.rs:14:5:
foo
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
------------------------------------------
```
Fixes#130996.
Check ABI target compatibility for function pointers
Tracking issue: https://github.com/rust-lang/rust/issues/130260
Related tracking issue: #87678
Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent.
This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea.
Also this might break existing code, because we now emit extra errors. Does this require a crater run?
# Example
```rust
// build with: --target=x86_64-unknown-linux-gnu
// These raise E0570
extern "thiscall" fn foo() {}
extern "thiscall" { fn bar() }
// This did not raise any error
fn baz(f: extern "thiscall" fn()) { f() }
```
# Open Questions
* [x] Should this report a future incompatibility warning like #87678 ?
* [ ] Is this the best place to perform the check?
std: fix stdout-before-main
Fixes#130210.
Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.
This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
Stabilize const `ptr::write*` and `mem::replace`
Since `const_mut_refs` and `const_refs_to_cell` have been stabilized, we may now also stabilize the ability to write to places during const evaluation inside our library API. So, we now propose the `const fn` version of `ptr::write` and its variants. This allows us to also stabilize `mem::replace` and `ptr::replace`.
- const `mem::replace`: https://github.com/rust-lang/rust/issues/83164#issuecomment-2338660862
- const `ptr::write{,_bytes,_unaligned}`: https://github.com/rust-lang/rust/issues/86302#issuecomment-2330275266
Their implementation requires an additional internal stabilization of `const_intrinsic_forget`, which is required for `*::write*` and thus `*::replace`. Thus we const-stabilize the internal intrinsics `forget`, `write_bytes`, and `write_via_move`.
Add suggestion for removing invalid path sep `::` in fn def
Add suggestion for removing invalid path separator `::` in function definition.
for example: `fn invalid_path_separator::<T>() {}`
fixes#130791
Fixes#130210.
Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.
This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
Remove deprecation note in the `non_local_definitions` lint
This PR removes the edition deprecation note emitted by the `non_local_definitions` lint.
Specifically this part:
```
= note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
```
because it [didn't make the cut](https://github.com/rust-lang/rust/issues/120363#issuecomment-2407833300) for the 2024 edition.
`@rustbot` label +L-non_local_definitions
Make unused_parens's suggestion considering expr's attributes.
For the expr with attributes,
like `let _ = (#[inline] || println!("Hello!"));`,
the suggestion's span should contains the attributes, or the suggestion will remove them.
fixes#129833
Support clobber_abi in MSP430 inline assembly
This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.
Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf)
cc ``@cr1901``
r? ``@Amanieu``
``@rustbot`` label +O-msp430
Otherwise `error-pattern` on the test run stderr can incorrectly match
if e.g. the paths in panic backtrace has a matching substring (like if
we look for `bar` in the error pattern but username is `baron`).
For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, the suggestion's span should contains the attributes, or the suggestion will remove them.
fixes#129833
`IndexRange::len` is justified as an overall invariant, and
`take_prefix` and `take_suffix` are justified by local branch
conditions. A few more UB-checked calls remain in cases that are only
supported locally by `debug_assert!`, which won't do anything in
distributed builds, so those UB checks may still be useful.
We generally expect core's `#![rustc_preserve_ub_checks]` to optimize
away in user's release builds, but the mere presence of that extra code
can sometimes inhibit optimization, as seen in #131563.
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.
https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
MIRI support is included for f32 and f64.
The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.
I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
Rollup of 6 pull requests
Successful merges:
- #129079 (Create `_imp__` symbols also when doing ThinLTO)
- #131208 (ABI: Pass aggregates by value on AIX)
- #131394 (fix(rustdoc): add space between struct fields and their descriptions)
- #131519 (Use Default visibility for rustc-generated C symbol declarations)
- #131541 (compiletest: Extract auxiliary-crate properties to their own module/struct)
- #131542 (next-solver: remove outdated FIXMEs)
r? `@ghost`
`@rustbot` modify labels: rollup
Use Default visibility for rustc-generated C symbol declarations
Non-default visibilities should only be used for definitions, not declarations, otherwise linking can fail.
This is based on https://github.com/rust-lang/rust/pull/123994.
Issue https://github.com/rust-lang/rust/issues/123427
When I changed `default-hidden-visibility` to `default-visibility` in https://github.com/rust-lang/rust/pull/130005, I updated all places in the code that used `default-hidden-visibility`, replicating the hidden-visibility bug to also happen for protected visibility.
Without this change, trying to build rustc with `-Z default-visibility=protected` fails with a link error.
ABI: Pass aggregates by value on AIX
On AIX we pass aggregates byval. Adds new ABI for AIX for powerpc64.
313ad85dfa/clang/lib/CodeGen/Targets/PPC.cpp (L216)
Fixes the following 2 testcases on AIX:
```
tests/ui/abi/extern/extern-pass-TwoU16s.rs
tests/ui/abi/extern/extern-pass-TwoU8s.rs
```
Create `_imp__` symbols also when doing ThinLTO
When generating a rlib crate on Windows we create `dllimport` / `_imp__` symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft's `link` can fix these up (and emits warnings), but `lld` seems to currently be unable to.
This PR also does this generation for ThinLTO avoiding those issues with `lld` and also avoids the warnings on `link`.
This is an workaround for https://github.com/rust-lang/rust/issues/81408.
cc `@lqd`
Retire the `unnamed_fields` feature for now
`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.
However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.
Fixes#117942Fixes#121161Fixes#121263Fixes#121299Fixes#121722Fixes#121799Fixes#126969Fixes#131041
Tracking:
* https://github.com/rust-lang/rust/issues/49804
[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
Consider outermost const-anon in `non_local_def` lint
This PR change the logic for finding the parent of the `impl` definition in the `non_local_definitions` lint to consider multiple level of const-anon items, instead of only one currently.
I also took the opportunity to cleanup the related code.
cc ``@traviscross``
Fixes https://github.com/rust-lang/rust/issues/131474
When making changes that have a large impact on coverage counter creation, this
makes it easier to see whether the number of physical counters has changed.
(The highest counter ID seen in coverage maps is not necessarily the same as
the number of physical counters actually used by the instrumented code, but
it's the best approximation we can get from looking only at the coverage maps,
and it should be reasonably accurate in most cases.)
compiletest: Remove the magic hacks for finding output with `lto=thin`
This hack was intended to handle the case where `-Clto=thin` causes the compiler to emit multiple output files (when producing LLVM-IR or assembly).
The hack only affects 4 tests, of which 3 are just meta-tests for the hack itself. The one remaining test that motivated the hack currently doesn't even need it!
(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
This hack was intended to handle the case where `-Clto=thin` causes the
compiler to emit multiple output files (when producing LLVM-IR or assembly).
The hack only affects 4 tests, of which 3 are just meta-tests for the hack
itself. The one remaining test that motivated the hack currently doesn't even
need it!
(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
Non-default visibilities should only be used for definitions, not
declarations, otherwise linking can fail.
Co-authored-by: Collin Baker <collinbaker@chromium.org>
Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible"
Follow-up to #130826.
Part of #130852.
1. 1st commit: Fix stupid oversights. Should've been part of #130826.
2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide.
3. 3rd commit: Apply the renaming to all UI tests (contents and paths).
Precise capturing in traits
This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work.
Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though.
I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs.
r? types
Tracking issue:
* #130044
rustc_target: Add sme-b16b16 as an explicit aarch64 target feature
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
Resolves https://github.com/rust-lang/rust/pull/129894.
codegen_ssa: consolidate tied target checks
Fixes#105110.
Fixes#105111.
`rustc_codegen_llvm` and `rustc_codegen_gcc` duplicated logic for checking if tied target features were partially enabled. This PR consolidates these checks into `rustc_codegen_ssa` in the `codegen_fn_attrs` query, which also is run pre-monomorphisation for each function, which ensures that this check is run for unused functions, as would be expected.
Also adds a test confirming that enabling one tied feature doesn't imply another - the appropriate error for this was already being emitted. I did a bisect and narrowed it down to two patches it was likely to be - something in #128796, probably #128221 or #128679.
Introduce SolverRelating type relation to the new solver
Redux of #128744.
Splits out relate for the new solver so that implementors don't need to implement it themselves.
r? lcnr
LLVM and Cranelift disagree about how to return values that don't fit
in the registers designated for return values. LLVM will force the
entire return value to be passed by return area pointer, while
Cranelift will look at each IR level return value independently and
decide to pass it in a register or not, which would result in the
return value being passed partially in registers and partially through
a return area pointer.
While Cranelift may need to be fixed as the LLVM behavior is generally
more correct with respect to the surface language, forcing this
behavior in rustc itself makes it easier for other backends to conform
to the Rust ABI and for the C ABI rustc already handles this behavior
anyway.
In addition LLVM's decision to pass the return value in registers or
using a return area pointer depends on how exactly the return type is
lowered to an LLVM IR type. For example `Option<u128>` can be lowered
as `{ i128, i128 }` in which case the x86_64 backend would use a return
area pointer, or it could be passed as `{ i32, i128 }` in which case
the x86_64 backend would pass it in registers by taking advantage of an
LLVM ABI extension that allows using 3 registers for the x86_64 sysv
call conv rather than the officially specified 2 registers.
This adjustment is only necessary for the Rust ABI as for other ABI's
the calling convention implementations in rustc_target already ensure
any return value which doesn't fit in the available amount of return
registers is passed in the right way for the current target.
The `Box<T: Default>` impl currently calls `T::default()` before allocating
the `Box`.
Most `Default` impls are trivial, which should in theory allow
LLVM to construct `T: Default` directly in the `Box` allocation when calling
`<Box<T>>::default()`.
However, the allocation may fail, which necessitates calling `T's` destructor if it has one.
If the destructor is non-trivial, then LLVM has a hard time proving that it's
sound to elide, which makes it construct `T` on the stack first, and then copy it into the allocation.
Create an uninit `Box` first, and then write `T::default` into it, so that LLVM now only needs to prove
that the `T::default` can't panic, which should be trivial for most `Default` impls.
fix/update teach_note from 'escaping mutable ref/ptr' const-check
The old note was quite confusing since it talked about statics, but the message is also shown for consts. So let's reword to something that is true for both of them.
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
Reserve guarded string literals (RFC 3593)
Implementation for RFC 3593, including:
- lexer / parser changes
- diagnostics
- migration lint
- tests
We reserve `#"`, `##"`, `###"`, `####`, and any other string of four or more repeated `#`. This avoids infinite lookahead in the lexer, though we still use infinite lookahead in the parser to provide better forward compatibility diagnostics.
This PR does not implement any special lexing of the string internals:
- strings preceded by one or more `#` are denied
- regardless of the number of trailing `#`
- string contents are lexed as if it was just a bare `"string"`
Tracking issue: #123735
RFC: rust-lang/rfcs#3593
Ignore broken-pipe-no-ice on apple (specifically macOS) for now
This test fails for me locally (initially reported by Zalathar) because apparently on macOS it doesn't say "internal compiler error" but it does report the std I/O panic, and it doesn't exit with a code of 101 but instead terminates with a wait signal of SIGPIPE.
Ignore this test on apple for now, until we try to actually address the underlying issue.
See https://github.com/rust-lang/rust/pull/131155 and https://github.com/rust-lang/rust/issues/131436 for more context.
Dont ICE when encountering post-mono layout cycle error
It's possible to encounter post-mono layout cycle errors in `fn_abi_of_instance`. Don't ICE in those cases.
This was originally discovered in an async fn, but that's not the only way to encounter such an error (which the other test I added should demonstrate).
Error messsages suck, but this fix is purely about suppressing the ICE.
Fixes#131409
Prevent building cargo from invalidating build cache of other tools due to conditionally applied `-Zon-broken-pipe=kill` via tracked `RUSTFLAGS`
This PR fixes#130980 where building cargo invalidated the tool build caches of other tools (such as rustdoc) because `-Zon-broken-pipe=kill` was conditionally passed via `RUSTFLAGS` for other tools *except* for cargo. The differing `RUSTFLAGS` triggered tool build cache invalidation as `RUSTFLAGS` is a tracked env var -- any changes in `RUSTFLAGS` requires a rebuild.
`-Zon-broken-pipe=kill` is load-bearing for rustc and rustdoc to not ICE on broken pipes due to usages of raw std `println!` that panics without the flag being set, which manifests in ICEs.
I can't say I like the changes here, but it is what it is...
See detailed discussions and history of `-Zon-broken-pipe=kill` usage in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F/near/474593815.
## Approach
This PR fixes the tool build cache invalidation by informing the `rustc` binary shim when to apply `-Zon-broken-pipe=kill` (i.e. when the rustc binary shim is not used to build cargo). This information is not communicated by `RUSTFLAGS`, which is an env var tracked by cargo, and instead uses an untracked env var `UNTRACKED_BROKEN_PIPE_FLAG` so we won't trigger tool build cache invalidation. We preserve bootstrap's behavior of not setting that flag for cargo by conditionally omitting setting `UNTRACKED_BROKEN_PIPE_FLAG` when building cargo.
Notably, the `-Zon-broken-pipe=kill` instance in 1e5719bdc4/src/bootstrap/src/core/build_steps/compile.rs (L1058) is not modified because that is used to build rustc only and not cargo itself.
Thanks to `@cuviper` for the idea!
## Testing
### Integration testing
This PR introduces a run-make test for rustc and rustdoc that checks that when they do not ICE/panic when they encounter a broken pipe of the stdout stream.
I checked this test will catch the broken pipe ICE regression for rustc on Linux (at least) by commenting out 1e5719bdc4/src/bootstrap/src/core/build_steps/compile.rs (L1058), and the test failed because rustc ICE'd.
### Manual testing
I have manually tried:
1. `./x clean && `./x test build --stage 1` -> `rustc +stage1 --print=sysroot | false`: no ICE.
2. `./x clean` -> `./x test run-make` twice: no stage 1 cargo rebuilds.
3. `./x clean` -> `./x build rustdoc` -> `rustdoc +stage1 --version | false`: no panics.
4. `./x test src/tools/cargo`: tests pass, notably `build::close_output` and `cargo_command::closed_output_ok` do not fail which would fail if cargo was built with `-Zon-broken-pipe=kill`.
## Related discussions
Thanks to everyone who helped!
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Applying.20.60-Zon-broken-pipe.3Dkill.60.20flags.20in.20bootstrap.3F
- https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Modifying.20run-make.20tests.20unnecessarily.20rebuild.20stage.201.20.2E.2E.2E
- https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F
Fixes https://github.com/rust-lang/rust/issues/130980
Closes https://github.com/rust-lang/rust/issues/131059
---
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
[Coverage][MCDC] Adapt mcdc to llvm 19
Related issue: #126672
Also finish task 4 at #124144
[llvm #82448](https://github.com/llvm/llvm-project/pull/82448) has introduced some break changes into mcdc, causing incompatibility between llvm 18 and 19. This draft adapts to that change and gives up supporting for llvm-18.
Fix utf8-bom test
The BOM was accidentally removed in https://github.com/rust-lang/rust/pull/57108
I had to move the run-pass line down, because compiletest doesn't seem to know about BOMs, so it does not parse the header if it is the first line.
Add tests for some old fixed issues
Closes#30867Closes#30472Closes#28994Closes#26719 (and migrates the relevant test to the new run-make)
Closes#23600
cc `@jieyouxu` for the run-make-support changes
try-job: x86_64-msvc
Add missing module flags for `-Zfunction-return=thunk-extern`
This fixes a bug in the `-Zfunction-return=thunk-extern` flag. The flag needs to be passed onto LLVM to ensure that functions such as `asan.module_ctor` and `asan.module_dtor` that are created internally in LLVM have the mitigation applied to them.
This was originally discovered [in the Linux kernel](https://lore.kernel.org/all/CANiq72myZL4_poCMuNFevtpYYc0V0embjSuKb7y=C+m3vVA_8g@mail.gmail.com/).
Original flag PR: #116892
PR for similar issue: #129373
Tracking issue: #116853
cc ``@ojeda``
r? ``@wesleywiser``
Add precondition checks to ptr::offset, ptr::add, ptr::sub
All of `offset`, `add`, and `sub` (currently) have the trivial preconditions that the offset in bytes must be <= isize::MAX, and the computation of the new address must not wrap. This adds precondition checks for these, and like in slice indexing, we use intrinsics directly to implement unsafe APIs that have explicit checks, because we get a clearer error message that mentions the misused API not an implementation detail.
Experimentation indicates these checks have 1-2% compile time overhead, due primarily to adding the checks for `add`.
A crater run (https://github.com/rust-lang/rust/pull/130251#issuecomment-2395824565) indicates some people currently have buggy calls to `ptr::offset` that apply a negative offset to a null pointer, but the crater run does not hit the `ptr::add` or `ptr::sub` checks, which seems like an argument for cfg'ing out those checks on account of their overhead.
Don't allow the `#[pointee]` attribute where it doesn't belong
Error if the `#[pointee]` attribute is applied to anything but generic type parameters.
Closes#128485
Related to #123430
liballoc: introduce String, Vec const-slicing
This change `const`-qualifies many methods on `Vec` and `String`, notably `as_slice`, `as_str`, `len`. These changes are made behind the unstable feature flag `const_vec_string_slice`.
## Motivation
This is to support simultaneous variance over ownership and constness. I have an enum type that may contain either `String` or `&str`, and I want to produce a `&str` from it in a possibly-`const` context.
```rust
enum StrOrString<'s> {
Str(&'s str),
String(String),
}
impl<'s> StrOrString<'s> {
const fn as_str(&self) -> &str {
match self {
// In a const-context, I really only expect to see this variant, but I can't switch the implementation
// in some mode like #[cfg(const)] -- there has to be a single body
Self::Str(s) => s,
// so this is a problem, since it's not `const`
Self::String(s) => s.as_str(),
}
}
}
```
Currently `String` and `Vec` don't support this, but can without functional changes. Similar logic applies for `len`, `capacity`, `is_empty`.
## Changes
The essential thing enabling this change is that `Unique::as_ptr` is `const`. This lets us convert `RawVec::ptr` -> `Vec::as_ptr` -> `Vec::as_slice` -> `String::as_str`.
I had to move the `Deref` implementations into `as_{str,slice}` because `Deref` isn't `#[const_trait]`, but I would expect this change to be invisible up to inlining. I moved the `DerefMut` implementations as well for uniformity.
Don't use Immediate::offset to transmute pointers to integers
This applies the relatively new `assert_matches_abi` check in the `offset` operation on immediates, which makes sure that if offsets are used to alter the layout (which is possible because the field layout is arbitrarily picked by the caller), this is not done in a way that breaks the invariant of the `Immediate` type.
This leads to ICEs in a GVN mir-opt test, so the second commit fixes GVN.
Fixes https://github.com/rust-lang/rust/issues/131064.
This change `const`-qualifies many methods on Vec and String, notably
`as_slice`, `as_str`, `len`. These changes are made behind the unstable
feature flag `const_vec_string_slice` with the following tracking issue:
https://github.com/rust-lang/rust/issues/129041
add `naked_asm!` macro for use in `#[naked]` functions
tracking issue: https://github.com/rust-lang/rust/issues/90957
Adds the `core::arch::naked_asm` macro, to be used in `#[naked]` functions, but providing better error messages and a place to explain the restrictions on assembly in naked functions.
This PR does not yet require that the `naked_asm!` macro is used inside of `#[naked]` functions:
- the `asm!` macro can still be used in `#[naked]` functions currently, with the same restrictions and error messages as before.
- the `naked_asm!` macro can be used outside of `#[naked]` functions. It has not yet been decided whether that should be allowed long-term.
In this PR, the parsing code of `naked_asm!` now enforces the restrictions on assembly in naked functions, with the exception of checking that the `noreturn` option is specified. It also has not currently been decided if `noreturn` should be implicit or not.
This PR looks large because it touches a bunch of tests. The code changes are mostly straightforward I think: we now have 3 flavors of assembly macro, and that information must be propagated through the parsing code and error messages.
cc `@Lokathor`
r? `@Amanieu`
- fix for divergence
- fix error message
- fix another cranelift test
- fix some cranelift things
- don't set the NORETURN option for naked asm
- fix use of naked_asm! in doc comment
- fix use of naked_asm! in run-make test
- use `span_bug` in unreachable branch
Make deprecated_cfg_attr_crate_type_name a hard error
Turns the forward compatibility lint added by #83744 into a hard error, so now, while the `#![crate_name]` and `#![crate_type]` attributes are still allowed in raw form, they are now forbidden to be nested inside a `#![cfg_attr()]` attribute.
The following will now be an error:
```Rust
#![cfg_attr(foo, crate_name = "foobar")]
#![cfg_attr(foo, crate_type = "bin")]
```
This code will continue working and is not deprecated:
```Rust
#![crate_name = "foobar"]
#![crate_type = "lib"]
```
The reasoning for this is explained in #83744: it allows us to not have to cfg-expand in order to determine the crate's type and name.
As of filing the PR, exactly two years have passed since #99784 has been merged, which has turned the lint's default warning level into an error, so there has been ample time to move off the now-forbidden syntax.
cc #91632 - tracking issue for the lint
On function and method calls in patterns, link to the book
```
error: expected a pattern, found an expression
--> f889.rs:3:13
|
3 | let (x, y.drop()) = (1, 2);
| ^^^^^^^^ not a pattern
|
= note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
error[E0532]: expected a pattern, found a function call
--> f889.rs:2:13
|
2 | let (x, drop(y)) = (1, 2);
| ^^^^ not a tuple struct or tuple variant
|
= note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
```
Fix#97200.
Do not consider match/let/ref of place that evaluates to `!` to diverge, disallow coercions from them too
Fixes#117288.
This PR implements a heuristic which disables two things that are currently being performed on the HIR when we have **expressions that involve place-like expressions that point to `!`**. Specifically, it will (in certain cases explained below):
### (1.) Disable the `NeverToAny` coercion we implicitly insert for `!`.
Which fixes this inadvertent, sneaky unsoundness:
```
unsafe {
let x: *const ! = &0 as *const u8 as *const !;
let _: () = *x;
}
```
which is UB because currently rust emits an *implicit* NeverToAny coercion even though we really shouldn't be, since there's no read of the value pointed by `x`.
### (2.) Disable the logic which considers expression which evaluate to `!` to diverge, which affects the type returned by the containing block.
Which fixes this unsoundness:
```
fn make_up_a_value<T>() -> T {
unsafe {
let x: *const ! = &0 as *const u8 as *const !;
let _ = *x;
}
}
```
We disable these two operations **if** the expression is a place-like expression (locals, statics, field projections, index operations, and deref operations), and if the parent expression is either:
(1.) the LHS of an assignment
(2.) AddrOf
(3.) A match or let **unless** all of the *patterns consitute a read*, which is explained below:
And finally, a pattern currently is considered to constitute a read **unless** it is a wildcard, or an OR pattern. An OR pattern is considered to constitute a read if all of its subpatterns constitute a read, to remain as conservative as possible in cases like `_ | subpat` or `subpat | _`.
All other patterns are considered currently to constitute a read. Specifically, because `NeverToAny` is a coercion performed on a *value* and not a *place*, `Struct { .. }` on a `!` type must be a coercion currently, and we currently rely on this behavior to allow us to perform coercions like `let _: i32 = x;` where `x: !`.
This is already considered UB by [miri](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=daf3a2246433fe43fdc07d1389c276c9), but also means it does not affect the preexisting UB in this case:
```
let Struct { .. } = *never_ptr;
```
Even though it's likely up for debate since we're not actually reading any data out of the struct, it almost certainly causes inference changes which I do *NOT* want to fix in this PR.
```
error: expected a pattern, found an expression
--> f889.rs:3:13
|
3 | let (x, y.drop()) = (1, 2); //~ ERROR
| ^^^^^^^^ not a pattern
|
= note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
error[E0532]: expected a pattern, found a function call
--> f889.rs:2:13
|
2 | let (x, drop(y)) = (1, 2); //~ ERROR
| ^^^^ not a tuple struct or tuple variant
|
= note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
```
Fix#97200.
Initial support for riscv32{e|em|emc}_unknown_none_elf
We have a research prototype of an RV32EMC target and have been successfully running the e, em, emc programs on it. I'm hoping upstreaming this configuration would make the target maintenance slightly easier.
Configuration is based on the respective {i, im, imc} variants. As defined in RISC-V Unprivileged Spec. 20191213, the only change in RVE wrt. RVI is to reduce the number of integer registers to 16 (x0-x15), which also implies
- 2 callee saved registers instead of 12
- 32-bit / 4-byte stack alignment instead of 128 bits / 16 bytes
My initial presumption is that this will not impact how the target is defined for the compiler but only becomes relevant at the runtime level. I am willing to investigate, though.
EDIT: LLVM is now told about the presumed 32-bit stack alignment.
`@Disasm` `@romancardenas`
Make opaque types regular HIR nodes
Having opaque types as HIR owner introduces all sorts of complications. This PR proposes to make them regular HIR nodes instead.
I haven't gone through all the test changes yet, so there may be a few surprises.
Many thanks to `@camelid` for the first draft.
Fixes https://github.com/rust-lang/rust/issues/129023Fixes#129099Fixes#125843Fixes#119716Fixes#121422
Account for `impl Trait {` when `impl Trait for Type {` was intended
On editions where bare traits are never allowed, detect if the user has written `impl Trait` with no type, silence any dyn-compatibility errors, and provide a structured suggestion for the potentially missing type:
```
error[E0782]: trait objects must include the `dyn` keyword
--> $DIR/missing-for-type-in-impl.rs:8:6
|
LL | impl Foo<i64> {
| ^^^^^^^^
|
help: add `dyn` keyword before this trait
|
LL | impl dyn Foo<i64> {
| +++
help: you might have intended to implement this trait for a given type
|
LL | impl Foo<i64> for /* Type */ {
| ++++++++++++++
```
CC #131051.
Add support for reborrowing pinned method receivers
This builds on #130526 to add pinned reborrowing for method receivers. This enables the folllowing examples to work:
```rust
#![feature(pin_ergonomics)]
#![allow(incomplete_features)]
use std::pin::Pin;
pub struct Foo;
impl Foo {
fn foo(self: Pin<&mut Self>) {
}
fn baz(self: Pin<&Self>) {
}
}
pub fn bar(x: Pin<&mut Foo>) {
x.foo();
x.foo();
x.baz(); // Pin<&mut Foo> is downgraded to Pin<&Foo>
}
pub fn baaz(x: Pin<&Foo>) {
x.baz();
x.baz();
}
```
This PR includes the original one, which is currently in the commit queue, but the only code changes are in the latest commit (d3c53aaa5c6fcb1018c58d229bc5d92202fa6880).
#130494
r? `@compiler-errors`
Check elaborated projections from dyn don't mention unconstrained late bound lifetimes
Check that the projections that are *not* explicitly written but which we deduce from elaborating the principal of a `dyn` *also* do not reference unconstrained late-bound lifetimes, just like the ones that the user writes by hand.
That is to say, given:
```
trait Foo<T>: Bar<Assoc = T> {}
trait Bar {
type Assoc;
}
```
The type `dyn for<'a> Foo<&'a T>` (basically) elaborates to `dyn for<'a> Foo<&'a T> + for<'a> Bar<Assoc = &'a T>`[^1]. However, the `Bar` projection predicate is not well-formed, since `'a` must show up in the trait's arguments to be referenced in the term of a projection. We must error in this situation[^well], or else `dyn for<'a> Foo<&'a T>` is unsound.
We already detect this for user-written projections during HIR->rustc_middle conversion, so this largely replicates that logic using the helper functions that were already conveniently defined.
---
I'm cratering this first to see the fallout; if it's minimal or zero, then let's land it as-is. If not, the way that this is implemented is very conducive to an FCW.
---
Fixes#130347
[^1]: We don't actually elaborate it like that in rustc; we only keep the principal trait ref `Foo<&'a T>` and the projection part of `Bar<Assoc = ...>`, but it's useful to be a bit verbose here for the purpose of explaining the issue.
[^well]: Well, we could also make `dyn for<'a> Foo<&'a T>` *not* implement `for<'a> Bar<Assoc = &'a T>`, but this is inconsistent with the case where the user writes `Assoc = ...` in the type itself, and it overly complicates the implementation of trait objects' built-in impls.
On editions where bare traits are never allowed, detect if the user has
written `impl Trait` with no type, silence any dyn-compatibility errors,
and provide a structured suggestion for the potentially missing type:
```
error[E0782]: trait objects must include the `dyn` keyword
--> $DIR/missing-for-type-in-impl.rs:8:6
|
LL | impl Foo<i64> {
| ^^^^^^^^
|
help: add `dyn` keyword before this trait
|
LL | impl dyn Foo<i64> {
| +++
help: you might have intended to implement this trait for a given type
|
LL | impl Foo<i64> for /* Type */ {
| ++++++++++++++
```
Fix `target_abi` in `sparc-unknown-none-elf`
This was previously set to `target_abi = "elf"`, but `elf` is not used elsewhere as a target ABI (even though there's many targets that have it in their name), so I've removed it.
CC target maintainer ``@jonathanpallant,`` what do you think about this?
``@rustbot`` label O-SPARC
Stabilize the `map`/`value` methods on `ControlFlow`
And fix the stability attribute on the `pub use` in `core::ops`.
libs-api in https://github.com/rust-lang/rust/issues/75744#issuecomment-2231214910 seemed reasonably happy with naming for these, so let's try for an FCP.
Summary:
```rust
impl<B, C> ControlFlow<B, C> {
pub fn break_value(self) -> Option<B>;
pub fn map_break<T>(self, f: impl FnOnce(B) -> T) -> ControlFlow<T, C>;
pub fn continue_value(self) -> Option<C>;
pub fn map_continue<T>(self, f: impl FnOnce(C) -> T) -> ControlFlow<B, T>;
}
```
Resolves#75744
``@rustbot`` label +needs-fcp +t-libs-api -t-libs
---
Aside, in case it keeps someone else from going down the same dead end: I looked at the `{break,continue}_value` methods and tried to make them `const` as part of this, but that's disallowed because of not having `const Drop`, so put it back to not even unstably-const.
Add x86_64-unknown-trusty as tier 3 target
This PR adds a third target for the Trusty platform, `x86_64-unknown-trusty`.
Please let me know if an MCP is required. https://github.com/rust-lang/compiler-team/issues/582 was made when adding the first two targets, I can make another one for the new target as well if needed.
# Target Tier Policy Acknowledgements
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
- Nicole LeGare (```@randomPoison)```
- Andrei Homescu (```@ahomescu)```
- Chris Wailes (chriswailes@google.com)
- As a fallback trusty-dev-team@google.com can be contacted
Note that this does not reflect the maintainers currently listed in [`trusty.md`](c52c23b6f4/src/doc/rustc/src/platform-support/trusty.md). #130452 is currently open to update the list of maintainers in the documentation.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
The new target `x86_64-unknown-trusty` follows the existing naming convention for similar targets.
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
👍
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
There are no known legal issues or license incompatibilities.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
👍
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
This PR only adds the target. `std` support is being worked on and will be added in a future PR.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
👍
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via ```@)``` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
👍
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
👍
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
👍
This was previously set to `target_abi = "elf"`, but `elf` is not used
elsewhere as a target ABI (even though there's many targets that have it
in their name).
Enable `--no-sandbox` option by default for rustdoc GUI tests
It's apparently common enough for people to have issues with the `sandbox` mode in chromium, so better disable it by default.
r? `@notriddle`
Implement RFC3695 Allow boolean literals as cfg predicates
This PR implements https://github.com/rust-lang/rfcs/pull/3695: allow boolean literals as cfg predicates, i.e. `cfg(true)` and `cfg(false)`.
r? `@nnethercote` *(or anyone with parser knowledge)*
cc `@clubby789`
