Fix ICE in tokenstream with contracts from parser recovery
Fixesrust-lang/rust#140683
After two times of parsing error, the `recover_stmt_` constructs an error ast, then when we expand macors, the invalid tokenstream triggered ICE because of mismatched delims.
Expected `{` and get other tokens is an obvious error message, too much effort on recovery may introduce noise.
r? ```@nnethercote```
rustdoc: linking to a local proc macro no longer warns
fixes https://github.com/rust-lang/rust/issues/91274
tried to keep the fix general in case we ever have any other kind of item that occupies
multiple namespaces simultaniously.
Improve intrinsic handling in cg_ssa
* Move all intrinsic handling code to the start of `codegen_call_terminator`.
* Push some intrinsic handling code into `codegen_intrinsic_call`.
* Don't depend on FnAbi for intrinsics.
Split `autodiff` into `autodiff_forward` and `autodiff_reverse`
This PR splits `#[autodiff]` macro so `#[autodiff(df, Reverse, args)]` would become `#[autodiff_reverse(df, args)]` and `#[autodiff(df, Forward, args)]` would become `#[autodiff_forwad(df, args)]`.
Add data_ptr method to Mutex and RwLock
Implementation of https://github.com/rust-lang/rust/issues/140368 / https://github.com/rust-lang/libs-team/issues/531.
I tried to write a useful safety section about when it is safe to read or write through the returned pointers, but couldn't come up with something nice. Hoping this PR is still useful without that. I'm happy to add any doc strings other people come up with if needed before merge, of course.
Unresolved questions:
- Return a `LockResult` or not?
- Return `*mut T` like existing APIs (`Cell::as_ptr` / `MaybeUninit::as[_mut]_ptr` / `Vec::as_ptr` / ...) or be more precise and return `NonNull<T>`?
This does not fully fix things, but it introduces a function that can be used to fix occurences.
When using `to_def` functionality, the input node needs to come from the macro expanded include, not the real file that was included.
This does unfortunately add more caller burden, but there is not really a way around it.
Disable libunwind cross-architecture unwinding
Building with _LIBUNWIND_IS_NATIVE_ONLY disables code for cross-architecture unwinding It also enables some additional code that handles PAC-specific unwind info it helps compiling with the -mbranch-protection=pac or -mbranch-protection=standard flags
This fixes build with clang/musl on aarch64
`concat_idents!` was deprecated in [1] and will be removed in the near
future. rust-analyzer's support is independent of rustc's, so drop RA
support now to make syncing easier.
[1]: https://github.com/rust-lang/rust/pull/137653
Building with _LIBUNWIND_IS_NATIVE_ONLY disables code for cross-architecture unwinding
it is disabled by default in LLVM [1], replicate the cmake behavior in bootstrap process
It also enables some additional code that handles PAC-specific unwind info
it helps compiling with the -mbranch-protection=pac or -mbranch-protection=standard flags
This fixes build with clang/musl on aarch64
[1] 85624c5de3
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Bump master `stage0` compiler
To include beta backport of revert rust-lang/rust#141024 which should undo linker warnings during bootstrapping of Windows MSVC targets due to rust-lang/rust#140176.
Closesrust-lang/rust#141395.
r? `@Mark-Simulacrum` (or release)
Make two transmute-related MIR lints into HIR lint
Make `PTR_TO_INTEGER_TRANSMUTE_IN_CONSTS` (rust-lang/rust#130540) and `UNNECESSARY_TRANSMUTES` (rust-lang/rust#136083) into "normal" HIR-based lints.
Funny enough this came up in the review of the latter (https://github.com/rust-lang/rust/pull/136083#issuecomment-2614301413), but I guess it just was overlooked.
But anywyas, there's no reason for these to be MIR lints; in fact, it makes the suggestions for them a bit more complicated than necessary.
Note that there's probably a few more simplifications and improvements to be done here. Follow-ups can be done in a separate PR, especially if they're about the messaging and suggestions themselves, which I didn't write.
gvn: bail out unavoidable non-ssa locals in repeat
Fixes#141251.
We cannot transform `*elem` to `array[idx1]` in the following code, as `idx1` has already been modified.
```rust
mir! {
let array;
let elem;
{
array = [*val; 5];
elem = &array[idx1];
idx1 = idx2;
RET = *elem;
Return()
}
}
```
Perhaps I could transform it to `array[0]`, but I prefer the conservative approach.
r? mir-opt
Make check-cfg diagnostics work in `#[doc(cfg(..))]`
This PR makes it so that the check-cfg `unexpected_cfgs` lint, is correctly emitted in `rustdoc`'s `#[doc(cfg(..))]`.
This is achieved by adding a custom trait to `cfg_matches` (the method that emits the lint) which permits `rustc` and `rustdoc` to each have their way to emitting lints (via buffered lints/AST for `rustc` and via `TyCtxt`/HIR for `rustdoc`).
The reason this is required is because buffered lints operates on the AST but `rustdoc` uses the HIR and by the time `rustdoc` calls `cfg_matches` we are way passed the point where buffered lints have been drain and emitted.
Best reviewed commit by commit.
r? `@jieyouxu` (for the compiler part)
r? `@GuillaumeGomez` (for the rustdoc part)
Add some track_caller info to precondition panics
Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.
I thought of this while looking at https://github.com/rust-lang/rust/pull/129642#issuecomment-2311703898.
The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces.
The perf implications of this are:
* Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out.
* The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU.
* The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
tests: mark option-niche-eq as fixed on LLVM 21
Some combination of recent Rust changes (between 3d86494a0d and aa57e46e24 from what I can tell) and changes in LLVM 21 (not recently, as best I can tell) have caused this test to start showing the behavior we want, so it's time to move this test to a proper place and mark it as fixed on LLVM 21.
~~Probably "fixes" rust-lang/rust#49892, but I'll let others make that call.~~
Closesrust-lang/rust#49892 unless we want to break out a dedicated issue for `Option<bool>::eq` on LLVM 20 (seems low-value).
`@rustbot` label llvm-main
coverage: Revert "unused local file IDs" due to empty function names
The changes to coverage metadata generation in rust-lang/rust#140847 appear to be the most likely cause of the `function name is empty` errors reported in rust-lang/rust#141577.
If that guess is correct, great. If not, no big deal.
---
This reverts commit 3b22c21dd8, reversing changes made to 5f292eea6d.
r? ghost
Rename `{GenericArg,Term}::unpack()` to `kind()`
A well-deserved rename IMO.
r? `@oli-obk` or `@lcnr` (or anyone)
cc `@rust-lang/types,` but I'd be surprised if this is controversial.
