Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
Stabilize const TypeId::of
fixesrust-lang/rust#77125
# Stabilization report for `const_type_id`
## General design
### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
N/A the constness was never RFCed
### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
`const_type_id` was kept unstable because we are currently unable to stabilize the `PartialEq` impl for it (in const contexts), so we feared people would transmute the type id to an integer and compare that integer.
### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
`TypeId::eq` is not const at this time, and will only become const once const traits are stable.
## Has a Call for Testing period been conducted? If so, what feedback was received?
This feature has been unstable for a long time, and most people just worked around it on stable by storing a pointer to `TypeId::of` and calling that at "runtime" (usually LLVM devirtualized the function pointer and inlined the call so there was no real performance difference).
A lot of people seem to be using the `const_type_id` feature gate (600 results for the feature gate on github: https://github.com/search?q=%22%23%21%5Bfeature%28const_type_id%29%5D%22&type=code)
We have had very little feedback except desire for stabilization being expressed.
## Implementation quality
Until these three PRs
* https://github.com/rust-lang/rust/pull/142789
* https://github.com/rust-lang/rust/pull/143696
* https://github.com/rust-lang/rust/pull/143736
there was no difference between the const eval feature and the runtime feature except that we prevented you from using `TypeId::of` at compile-time. These three recent PRs have hardened the internals of `TypeId`:
* it now contains an array of pointers instead of integers
* these pointers at compile-time (and in miri) contain provenance that makes them unique and prevents inspection. Both miri and CTFE will in fact error if you mess with the bits or the provenance of the pointers in any way and then try to use the `TypeId` for an equality check. This also guards against creating values of type `TypeId` by any means other than `TypeId::of`
### Summarize the major parts of the implementation and provide links into the code (or to PRs)
N/A see above
### Summarize existing test coverage of this feature
Since we are not stabilizing any operations on `TypeId` except for creating `TypeId`s, the test coverage of the runtime implementation of `TypeId` covers all the interesting use cases not in the list below
#### Hardening against transmutes
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id.rs
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id2.rs
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id3.rs
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id4.rs
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id5.rs
#### TypeId::eq is still unstable
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_cmp_type_id.rs
### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
https://github.com/rust-lang/rust/issues/129014 is still unresolved, but it affects more the runtime version of `TypeId` than the compile-time.
### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
none
### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
* `@eddyb`
* `@RalfJung`
### Which tools need to be adjusted to support this feature. Has this work been done?
N/A
## Type system and execution rules
### What compilation-time checks are done that are needed to prevent undefined behavior?
Already covered above. Transmuting types with private fields to expose those fields has always been library UB, but for the specific case of `TypeId` CTFE and Miri will detect it if that is done in any way other than for reconstructing the exact same `TypeId` in another location.
### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale?
N/A
### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.)
N/A
### What updates are needed to the reference/specification? (link to PRs when they exist)
Nothing more than what needs to exist for `TypeId` already.
## Common interactions
### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
N/A
### What other unstable features may be exposed by this feature?
N/A
Print thread ID in panic message
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (12345) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: dist-apple-various
try-job: dist-various-*
try-job: dist-x86_64-freebsd
try-job: dist-x86_64-illumos
try-job: dist-x86_64-netbsd
try-job: dist-x86_64-solaris
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-mingw-1
try-job: x86_64-msvc-1
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
Rehome 21 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that ``@Kivooeo`` was using.
r? ``@jieyouxu``
`tests/ui/issues/`: The Issues Strike Back [2/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ``@jieyouxu``
expand: Micro-optimize prelude injection
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
Stop compilation early if macro expansion failed
Fixesrust-lang/rust#116180.
So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in https://github.com/rust-lang/rust/pull/133937 and suggested by ````@estebank```` in https://github.com/rust-lang/rust/issues/116180#issuecomment-3109468922. But maybe I missed something?
So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it.
There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is.
r? ````@oli-obk````
Key changes include:
- Removal of the word "syntax" from the lint message. More accurately,
it could have been something like "syntax group" or "syntax
category", but avoiding it completely is easier.
- The primary lint message now reflects exactly which mismatch is
occurring, instead of trying to be general. A new `help` line is
general across the mismatch kinds.
- Suggestions have been reduced to be more minimal, no longer also
changing non-idiomatic but unrelated aspects.
- Suggestion text no longer mentions changes when those changes don't
occur in that specific suggestion.
Check assoc consts and tys later like assoc fns
This PR
1. checks assoc consts and tys later like assoc fns
2. marks assoc consts appear in poly-trait-ref live
For assoc consts, considering
```rust
#![deny(dead_code)]
trait Tr { // ERROR trait `Tr` is never used
const I: Self;
}
struct Foo; //~ ERROR struct `Foo` is never constructed
impl Tr for Foo {
const I: Self = Foo;
}
fn main() {}
```
Current this will produce unused `I` instead of unused `Tr` and `Foo` ([play](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=e0490d4a2d522cb70437b26e514a3d9c)), because `const I: Self = Foo;` will be added into the worklist at first:
```
error: associated constant `I` is never used
--> src/main.rs:4:11
|
3 | trait Tr { // ERROR trait `Tr` is never used
| -- associated constant in this trait
4 | const I: Self;
| ^
|
note: the lint level is defined here
--> src/main.rs:1:9
|
1 | #![deny(dead_code)]
| ^^^^^^^^^
error: could not compile `playground` (bin "playground") due to 1 previous error
```
This also happens to assoc tys, see the [new test](https://github.com/rust-lang/rust/compare/master...mu001999-contrib:rust:dead-code/impl-items?expand=1#diff-bf45fa403934a31c9d610a073ed2603d885e7e81572e8edf38b7f4e08a1f3531)
Fixesrust-lang/rust#126729
r? `````@petrochenkov`````
New tracking issues for const_ops and const_cmp
Let's do a clean start with new tracking issues to avoid mixing things up with the previous constification.
I assume the fact that the `PartialEq` *trait* and *impls* used different feature names was a mistake (the feature name on the impl is entirely irrelevant anyway).
Part of https://github.com/rust-lang/rust/issues/143800, https://github.com/rust-lang/rust/issues/143802
r? ``@oli-obk``
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143403 (Port several trait/coherence-related attributes the new attribute system)
- rust-lang/rust#143633 (fix: correct assertion to check for 'noinline' attribute presence before removal)
- rust-lang/rust#143647 (Clarify and expand documentation for std::sys_common dependency structure)
- rust-lang/rust#143716 (compiler: doc/comment some codegen-for-functions interfaces)
- rust-lang/rust#143747 (Add target maintainer information for aarch64-unknown-linux-musl)
- rust-lang/rust#143759 (Fix typos in function names in the `target_feature` test)
- rust-lang/rust#143767 (Bump `src/tools/x` to Edition 2024 and some cleanups)
- rust-lang/rust#143769 (Remove support for SwitchInt edge effects in backward dataflow)
- rust-lang/rust#143770 (build-helper: clippy fixes)
r? `@ghost`
`@rustbot` modify labels: rollup
Port several trait/coherence-related attributes the new attribute system
Part of rust-lang/rust#131229
This ports:
- `#[const_trait]`
- `#[rustc_deny_explicit_impl]`
- `#[rustc_do_not_implement_via_object]`
- `#[rustc_coinductive]`
- `#[type_const]`
- `#[rustc_specialization_trait]`
- `#[rustc_unsafe_specialization_marker]`
- `#[marker]`
- `#[fundamental]`
- `#[rustc_paren_sugar]`
- `#[rustc_allow_incoherent_impl]`
- `#[rustc_coherence_is_core]`
This also changes `#[marker]` to error on duplicates instead of warning.
cc rust-lang/rust#142838, but I don't think it matters too much, since it's unstable.
r? ``@oli-obk``
When a trait bound fails due to the Self type parameter, adjust_fulfillment_errors
now correctly points to the corresponding function argument instead of incorrectly
pointing to other arguments.
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
gce: don't ICE on non-local const
Fixesrust-lang/rust#133808
I have absolutely no idea what I'm doing here, but I followed `@BoxyUwU` 's [instructions](https://github.com/rust-lang/rust/issues/133808#issuecomment-3009122957), and turns out this small change fixesrust-lang/rust#133808, and doesn't seem to break anything else.
(This code path is only reachable when the GCE feature gate is enabled, so even if it does break in a way that is not caught by current test coverage, I guess it's not as bad as breaking stable or non-incomplete features?)
Anyways, r? `@BoxyUwU` , if you don't mind.
New const traits syntax
This PR only affects the AST and doesn't actually change anything semantically.
All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser
Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error
r? ``@fee1-dead``
cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
Marks ADT live if it appears in pattern
Marks ADT live if it appears in pattern, it implies the construction of the ADT.
1. Then we can detect unused private ADTs impl `Default`, without special logics for `Default` and other std traits.
2. We can also remove `rustc_trivial_field_reads` on `Default`, and the logic in `should_ignore_item` (introduced by rust-lang/rust#126302).
Fixesrust-lang/rust#120770
Extracted from rust-lang/rust#128637.
r? `@petrochenkov`
These tests just need blessing, they don't have any interesting behaviour
changes.
Some of these tests have new errors because `LegacyReceiver` cannot be
proven to be implemented now that it is also testing for `MetaSized` -
but this is just a consequence of the other errors in the test.
