We want to evaluate the rhs of a type_const.
Also added an early return/guard in eval_in_interpreter which is used in functions like `eval_to_allocation_raw_provider`
Lastly add a debug assert to `thir_body()` if we have gotten there with a type_const something as gone wrong.
Get rid of a call to is_type_const() and instead use a match arm.
Change this is_type_const() check to a debug_assert!()
Change to use an if else statment instead.
Update type_const-pub.rs
Fix formatting.
Noticed that this is the same check as is_type_const() centralize it.
Add test case for pub type_const.
Remove `Deref`/`DerefMut` impl for `Providers`.
It's described as a "backwards compatibility hack to keep the diff small". Removing it requires only a modest amount of churn, and the resulting code is clearer without the invisible derefs.
r? @oli-obk
It's described as a "backwards compatibility hack to keep the diff
small". Removing it requires only a modest amount of churn, and the
resulting code is clearer without the invisible derefs.
Move some checks from `check_doc_attrs` directly into `rustc_attr_parsing`
Part of https://github.com/rust-lang/rust/issues/149865.
I also used this opportunity to remove the `id_is_crate_root` method.
Once this is merged, I think I'll try to see if we can remove `target_id` as well.
r? @JonathanBrouwer
Port `#[collapse_debuginfo]` to the new attribute parsing system
Tracking issue: https://github.com/rust-lang/rust/issues/131229
Felt like doing one again, has been a while :3
r? @jdonszelmann
Port `#[cfg]` and `#[cfg_attr]` trace attributes to the new attribute parsers
This PR converts `cfg` and `cfg_trace` attributes to the new parsed representation.
The primary challenge is that re-parsing these attributes in the HIR is a performance regression, since these attributes were only used in rustdoc and clippy parsing them in the HIR is extra work that was not done in the compiler before. To solve this, we only parse the attributes once and then store their parsed representation in the AST.
Port `#[instruction_set]` to attribute parser
Please note the test changes, and deprecation of `E0778` and `E0779`
In my opinion, all errors related to this attribute are improved I think, except for if you have `#[instruction_set(arm::)]` in which case there's an `error: expected identifier, found <eof>`, which is quite unhelpful I think, but this seems to be a limitation of the general attribute parsing flow
r? `@JonathanBrouwer`
Don't use `matches!` when `==` suffices
In the codebase we sometimes use `matches!` for values that can actually just be compared. Replace them with `==`.
Subset of rust-lang/rust#149933.
Port `#[rustc_must_implement_one_of]` to attribute parser
Stumbled upon a weird (bug ?) behaviour while making this PR
it seems like it is possible to reach `check_attr.rs` checks without the attribute allowed target checks having already been finished, I added a comment about how to reproduce this in `check_attr.rs`
otherwise good to note is that a bunch of code was moved from `compiler/rustc_hir_analysis/src/collect.rs` to `check_attr.rs`
r? `@JonathanBrouwer`
Fixed ICE for EII with multiple defaults due to duplicate definition in nameres
r? ``@jieyouxu`` (since you looked at the other one)
Fixes https://github.com/rust-lang/rust/issues/149982
Previously a [fix was proposed](https://github.com/rust-lang/rust/pull/149985) by ``@SATVIKsynopsis`` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR.
Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined.
Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption.
The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error.
Thanks to ``@SATVIKsynopsis`` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3
Also thanks to ``@yaahc`` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3
The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)
Port #[no_link] to use attribute parser
Adds `#[no_link]` to the attribute parser, as well as adds tests making sure to FCW warn on `field`, `arm`, and `macrodef `
