Do not get proc_macro from the sysroot in rustc
With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work.
To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
<rustc_metadata::creader::CStore>::push_dependencies_in_postorder showed up in new benchmarks from https://github.com/rust-lang/rustc-perf/pull/2143, hence I gave it a shot to remove an obvious O(n) there.
PR 138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fix Issue 56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.
```
warning: unused extern crate
--> $DIR/removing-extern-crate.rs:9:1
|
LL | extern crate removing_extern_crate as foo;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
|
note: the lint level is defined here
--> $DIR/removing-extern-crate.rs:6:9
|
LL | #![warn(rust_2018_idioms)]
| ^^^^^^^^^^^^^^^^
= note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
|
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
LL +
|
```
Rollup of 16 pull requests
Successful merges:
- rust-lang/rust#136429 (GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants)
- rust-lang/rust#138139 (Emit warning while outputs is not exe and prints linkage info)
- rust-lang/rust#141104 (Test(fs): Fix `test_eq_windows_file_type` for Windows 7)
- rust-lang/rust#141477 (Path::with_extension: show that it adds an extension where one did no…)
- rust-lang/rust#141533 (clean up old rintf leftovers)
- rust-lang/rust#141612 (Call out possibility of invariant result in variance markers)
- rust-lang/rust#141638 (Use `builtin_index` instead of hand-rolling it)
- rust-lang/rust#141643 (ci: verify that codebuild jobs use ghcr.io)
- rust-lang/rust#141675 (Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.)
- rust-lang/rust#141680 (replace TraitRef link memory.md)
- rust-lang/rust#141682 (interpret/allocation: Fixup type for `alloc_bytes`)
- rust-lang/rust#141683 (Handle ed2021 precise capturing of unsafe binder)
- rust-lang/rust#141684 (rustbook: Bump versions of `onig` and `onig_sys`)
- rust-lang/rust#141687 (core: unstably expose atomic_compare_exchange so stdarch can use it)
- rust-lang/rust#141690 (Add `rustc_diagnostic_item` to `sys::Mutex` methods)
- rust-lang/rust#141702 (Add eholk to compiler reviewer rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Stabilize `repr128`
## Stabilisation report
The `repr128` feature ([tracking issue](https://github.com/rust-lang/rust/issues/56071)) allows the use of `#[repr(u128)]` and `#[repr(i128)]` on enums in the same way that other primitive representations such as `#[repr(u64)]` can be used. For example:
```rust
#[repr(u128)]
enum Foo {
One = 1,
Two,
Big = u128::MAX,
}
#[repr(i128)]
enum Bar {
HasThing(u16) = 42,
HasSomethingElse(i64) = u64::MAX as i128 + 1,
HasNothing,
}
```
This is the final part of adding 128-bit integers to Rust ([RFC 1504](https://rust-lang.github.io/rfcs/1504-int128.html)); all other parts of 128-bit integer support were stabilised in #49101 back in 2018.
From a design perspective, `#[repr(u128)]`/`#[repr(i128)]` function like `#[repr(u64)]`/`#[repr(i64)]` but for 128-bit integers instead of 64-bit integers. The only differences are:
- FFI safety: as `u128`/`i128` are not currently considered FFI safe, neither are `#[repr(u128)]`/`#[repr(i128)]` enums (I discovered this wasn't the case while drafting this stabilisation report, so I have submitted #138282 to fix this).
- Debug info: while none of the major debuggers currently support 128-bit integers, as of LLVM 20 `rustc` will emit valid debuginfo for both DWARF and PDB (PDB makes use of the same natvis that is also used for all enums with fields, whereas DWARF has native support).
Tests for `#[repr(u128)]`/`#[repr(i128)]` enums include:
- [ui/enum-discriminant/repr128.rs](385970f0c1/tests/ui/enum-discriminant/repr128.rs): checks that 128-bit enum discriminants have the correct values.
- [debuginfo/msvc-pretty-enums.rs](385970f0c1/tests/debuginfo/msvc-pretty-enums.rs): checks the PDB debuginfo is correct.
- [run-make/repr128-dwarf](385970f0c1/tests/run-make/repr128-dwarf/rmake.rs): checks the DWARF debuginfo is correct.
Stabilising this feature does not require any changes to the Rust Reference as [the documentation on primitive representations](https://doc.rust-lang.org/nightly/reference/type-layout.html#r-layout.repr.primitive.intro) already includes `u128` and `i128`.
Closes#56071
Closes https://github.com/rust-lang/reference/issues/1368
r? lang
```@rustbot``` label +I-lang-nominated +T-lang
Add `rustc_diagnostic_item` to `sys::Mutex` methods
For an ongoing project for adding a concurrency model checker to Miri we need to be able to intercept locking/unlocking operations on standard library mutexes.
This PR adds diagnostic items to the relevant calls `lock`, `try_lock` and `unlock` for the `sys::Mutex` implementation on the targets we care about.
This PR also makes the internals of `pthread::Mutex` less public, to reduce the chance of anyone locking/unlocking a mutex without going through the intercepted methods.
r? ``@RalfJung``
Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
r? `@fee1-dead`
Emit warning while outputs is not exe and prints linkage info
cc #137384
```bash
$ rustc +stage1 /dev/null --print native-static-libs --crate-type staticlib --emit metadata
warning: skipping link step due to conflict: cannot output linkage information without emitting executable
note: consider emitting executable to print link information
warning: 1 warning emitted
```
GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants
* 1st commit: Partially addresses [#136204](https://github.com/rust-lang/rust/issues/136204) by turning const eval errors from post to pre-mono for free lifetime-generic constants.
* As the linked issue/comment states, on master there's a difference between `const _: () = panic!();` (pre-mono error) and `const _<'a>: () = panic!();` (post-mono error) which feels wrong.
* With this PR, both become pre-mono ones!
* 2nd commit: Oof, yeah, I missed that in the initial impl!
This doesn't fully address #136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `const _UNUSED: () = () where for<'_delay> String: Copy;` which can also be found over at the tracking issue #113521.
r? compiler-errors or reassign
add additional `TypeFlags` fast paths
Some crates, e.g. `diesel`, have items with a lot of where-clauses (more than 150). In these cases checking the `TypeFlags` of the whole `param_env` can be very beneficial.
This adds `fn fold_clauses` to mirror the existing `fn visit_clauses` and then uses this in folders which fold `ParamEnv`s.
Split out from rust-lang/rust#141451, depends on rust-lang/rust#141442.
r? `@compiler-errors`
There is no safety contract and I don't think any of them can actually
cause UB in more ways than passing malicious source code to rustc can.
While LtoModuleCodegen::optimize says that the returned ModuleCodegen
points into the LTO module, the LTO module has already been dropped by
the time this function returns, so if the returned ModuleCodegen indeed
points into the LTO module, we would have seen crashes on every LTO
compilation, which we don't. As such the comment is outdated.
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```
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)]`.
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
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.
