Retire hir::*ItemRef.
This information was kept for various places that iterate on HIR to know about trait-items and impl-items.
This PR replaces them by uses of the `associated_items` query that contain pretty much the same information.
This shortens many spans to just `def_span`, which can be easier to read.
make `cfg_select` a builtin macro
tracking issue: https://github.com/rust-lang/rust/issues/115585
This parses mostly the same as the `macro cfg_select` version, except:
1. wrapping in double brackets is no longer supported (or needed): `cfg_select {{ /* ... */ }}` is now rejected.
2. in an expression context, the rhs is no longer wrapped in a block, so that this now works:
```rust
fn main() {
println!(cfg_select! {
unix => { "foo" }
_ => { "bar" }
});
}
```
3. a single wildcard rule is now supported: `cfg_select { _ => 1 }` now works
I've also added an error if none of the rules evaluate to true, and warnings for any arms that follow the `_` wildcard rule.
cc `@traviscross` if I'm missing any feature that should/should not be included
r? `@petrochenkov` for the macro logic details
constify `From` and `Into`
tracking issue rust-lang/rust#143773
r? ``````@fee1-dead``````
I did not mark any impls elsewhere as `const`, those can happen on their own timeframe and don't need to be part of this MVP. But if there are some core ones you think should be in there I'll happily add them, just couldn't think of any
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`````
`tests/ui`: A New Order [26/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ````@tgross35````
Run `tests/rustdoc-json/attrs/target_features` on all hosts.
Makes it more convenient to test rustdoc on non x86_64. I mainly care about the aarch64 dev-desktops.
This works because rustdoc uses all target features, not just that of the target.
Massage the `symbols` helpers to fill out {match all, match any} x
{substring match, exact match}:
| | Substring match | Exact match |
|-----------|----------------------------------------|-------------------------------|
| Match any | `object_contains_any_symbol_substring` | `object_contains_any_symbol` |
| Match all | `object_contains_all_symbol_substring` | `object_contains_all_symbols` |
As part of this, rename `any_symbol_contains` to
`object_contains_any_symbol_substring` for accuracy.
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``
Disambiguate between rustc vs std having debug assertions in `run-make-support` and `run-make` tests
`NO_DEBUG_ASSERTIONS` is set by CI that threads through to the `./configure.py` script, which is somewhat fragile and "spooky action at a distance". For `fmt-write-bloat`, this is actually wrong because the test wants to gate on *std* being built with debug assertions or not, whereas `NO_DEBUG_ASSERTIONS` determines *rustc* being built with debug assertions or not. Instead, use env vars controlled by compiletest, whose debug assertion info comes from bootstrap.
855e0fe46e/src/ci/run.sh (L137-L146)
`NO_DEBUG_ASSERTIONS` controls `--enable-debug-assertions`
855e0fe46e/src/bootstrap/configure.py (L124)
which sets `--rust.debug-assertions`, which controls *rustc* debug assertions.
855e0fe46e/src/bootstrap/configure.py (L125-L129)
`--rust.debug-assertions-std` controls *std* debug assertions.
Noticed while investigating `fmt-write-bloat` in https://github.com/rust-lang/rust/pull/143669#discussion_r2200522215.
Best reviewed commit-by-commit.
r? ``@ChrisDenton`` (or compiler/bootstrap)
Split up the `unknown_or_malformed_diagnostic_attributes` lint
This splits up the lint into the following lint group:
- `unknown_diagnostic_attributes` - triggers if the attribute is unknown to the current compiler
- `misplaced_diagnostic_attributes` - triggers if the attribute exists but it is not placed on the item kind it's meant for
- `malformed_diagnostic_attributes` - triggers if the attribute's syntax or options are invalid
- `malformed_diagnostic_format_literals` - triggers if the format string literal is invalid, for example if it has unpaired curly braces or invalid parameters
- this pr doesn't create it, but future lints for things like deprecations can also go here.
This PR does not start emitting lints in places that previously did not.
## Motivation
I want to have finer control over what `unknown_or_malformed_diagnostic_attributes` does
I have a project with fairly low msrv that is/will have a lower msrv than future diagnostic attributes. So lints will be emitted when I or others compile it on a lower msrv.
At this time, there are two options to silence these lints:
- `#[allow(unknown_or_malformed_diagnostic_attributes)]` - this risks diagnostic regressions if I (or others) mess up using the attribute, or if the attribute's syntax ever changes.
- write a build script to detect the compiler version and emit cfgs, and then conditionally enable the attribute:
```rust
#[cfg_attr(rust_version_99, diagnostic::new_attr_in_rust_99(thing = ..))]`
struct Foo;
```
or conditionally `allow` the lint:
```rust
// lib.rs
#![cfg_attr(not(current_rust), allow(unknown_or_malformed_diagnostic_attributes))]
```
I like to avoid using build scripts if I can, so the following works much better for me. That is what this PR will let me do in the future:
```rust
#[allow(unknown_diagnostic_attribute, reason = "attribute came out in rust 1.99 but msrv is 1.70")]
#[diagnostic::new_attr_in_rust_99(thing = ..)]`
struct Foo;
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``
Make UB transmutes really UB in LLVM
Ralf suggested in <https://github.com/rust-lang/rust/pull/143410#discussion_r2184928123> that UB transmutes shouldn't be trapping, which happened for the one path *that* PR was changing, but there's another path as well, so *this* PR changes that other path to match.
r? codegen
fix: Include frontmatter in -Zunpretty output
In the implementation (rust-lang/rust#140035), this was left as an open question for
the tracking issue (rust-lang/rust#136889). My assumption is that this should be
carried over.
The test was carried over from rust-lang/rust#137193 which was superseded by rust-lang/rust#140035.
Thankfully, either way, `-Zunpretty` is unstable and we can always
change it even if we stabilize frontmatter.
chore: Improve how the other suggestions message gets rendered
Note: This change is part of my ongoing work to use `annotate-snippets` as `rustc`'s emitter
This change started as a way to remove some specialty code paths from `annotate-snippets`, by making the "and {} other candidates" message get rendered like a secondary message with no level, but turned into a fix for the message's Unicode output. Before this change, when using the Unicode output, the other suggestions message would get rendered outside of the main suggestion block, making it feel disconnected from what it was referring to. This change makes it so that the message is on the last line of the block, aligning its rendering with other secondary messages, and making it clear what the message is referring to.
Before:
```
error[E0433]: failed to resolve: use of undeclared type `IntoIter`
╭▸ $DIR/issue-82956.rs:28:24
│
LL │ let mut iter = IntoIter::new(self);
│ ━━━━━━━━ use of undeclared type `IntoIter`
╰╴
help: consider importing one of these structs
╭╴
LL + use std::array::IntoIter;
├╴
LL + use std::collections::binary_heap::IntoIter;
├╴
LL + use std::collections::btree_map::IntoIter;
├╴
LL + use std::collections::btree_set::IntoIter;
╰╴
and 9 other candidates
```
After:
```
error[E0433]: failed to resolve: use of undeclared type `IntoIter`
╭▸ $DIR/issue-82956.rs:28:24
│
LL │ let mut iter = IntoIter::new(self);
│ ━━━━━━━━ use of undeclared type `IntoIter`
╰╴
help: consider importing one of these structs
╭╴
LL + use std::array::IntoIter;
├╴
LL + use std::collections::binary_heap::IntoIter;
├╴
LL + use std::collections::btree_map::IntoIter;
├╴
LL + use std::collections::btree_set::IntoIter;
│
╰ and 9 other candidates
```
`tests/ui`: A New Order [28/28] FINAL PART
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@tgross35``
`tests/ui`: A New Order [27/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@tgross35``
