Use `find_attr` instead of `attr::contains_name` in `lower_const_item_rhs`
Fixesrust-lang/rust#151250
`attr::contains_name` uses `AttributeExt::name()` to filter, but for `hir::Attribute::Parsed`, this method will return `None`, and then `attr::contains_name` will return `false` here. So that the previous logic cannot work as expected.
r? @BoxyUwU
Normalize type_const items even with feature `generic_const_exprs`
Fixesrust-lang/rust#151251
With feature `generic_const_exprs` enabled, consts with `#[type_const]` won't be normalized even if they need. Then ICE happens when CTFE tries to evaluate such const without body.
Fix this by normalizing such consts even with feature `generic_const_exprs` enabled.
r? @BoxyUwU
Fix ICE on inconsistent import resolution with macro-attributed extern crate
Fixesrust-lang/rust#151213 using issue_145575_hack_applied in the same way as in rust-lang/rust#149860.
Allow invoking all help options at once
Implements rust-lang/rust#150442
Help messages are printed in the order they are invoked, but only once (e.g. `--help -C help --help` prints regular help then codegen help).
Lint groups (`-Whelp`) are always printed last due to necessarily coming later in the compiler pipeline.
Adds `help` flags to `-C` and `-Z` to avoid an error in `build_session_options`.
cc @bjorn3 [#t-compiler/major changes > Allow combining `--help -C help -Z help -… compiler-team#954 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Allow.20combining.20.60--help.20-C.20help.20-Z.20help.20-.E2.80.A6.20compiler-team.23954/near/564358190) - this currently maintains the behaviour of unrecognized options always failing-fast, as this happens within `getopt`s parsing, before we can even check if help options are present.
Port #[needs_allocator] to attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
Ports needs_allocator attribute to the new attribute parser.
Note: this is a deprecated and feature gated attribute.
Fix ICE: When Trying to check visibility of a #[type_const], check RHS instead.
This PR fixes https://github.com/rust-lang/rust/issues/150956 for min_const_generic_args https://github.com/rust-lang/rust/issues/132980.
The first part of this PR checks in `reachable.rs` if we have a type const use `visit_const_item_rhs(init);` instead of calling `const_eval_poly_to_alloc()`
The second part is I noticed that if `const_eval_poly_to_alloc()` returns a `ErrorHandled::TooGeneric` then switches to `visit_const_item_rhs()`. So further up `const_eval_poly_to_alloc()` call order it eventual gets to `eval_in_interpreter()`. So I added a debug_assert in `eval_in_interpreter()` if we happen to try and run CTFE on a `type_const`.
The other bit is just a test case, and some duplicated code I noticed.
While the PR does get rid of the ICE for a type_const with `pub` visibility. If I try using the const though it will ICE with the following:
```
error: internal compiler error: /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13: expected ConstKind::Param or ConstKind::Value here, found UnevaluatedConst { def: DefId(20:4 ~ colorkit[c783]::TYPE_CONST), args: [] }
thread 'rustc' (819687) panicked at /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13:
```
I suspect it is a similar issue to inherent associated consts. Since if I apply the same fix I had here:
https://github.com/rust-lang/rust/pull/150799#discussion_r2676504639
I then can use the const internally and in external crates without any issues.
Although, did not include that fix since if it is a similar issue it would need to be addressed elsewhere.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
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.
Add missing closing brackets to THIR output.
Closing brackets were missing on AdtDef, the field_types list in FruInfo, and InlineAsmExpr, breaking folding in some editors; Fields were incorrectly (?) indexed in the list for functional update syntax, showing the (implicit, irrelevant) iteration index instead of the field index; also spurious colon after Pat.
Add an additional help note to the ambiguity lint error
This PR adds an additional help note to the ambiguity lint error output to ask users updating their dependencies. This hopefully helps with cases like rust-lang/rust#149845 where newer crate versions are fixed.
r? @petrochenkov
Closing brackets were missing on AdtDef, the field_types list in FruInfo, and InlineAsmExpr, breaking folding in some editors;
Fields were incorrectly (?) indexed in the list for functional update syntax, showing the (implicit, irrelevant) iteration index instead of the field index;
also spurious colon after Pat.
Clean up `rustc_attr_parsing`
Follow-up of rust-lang/rust#150934.
It removes the `Option<>` wrapping for `SharedContext::target` field and completely removed the `target_id` field. Considering this type contains a closure and never updates its `target_id` field, there is no need to keep it around, it can be used directly in the lint emitter.
r? @JonathanBrouwer
Revert `QueryStackFrame` split
PR rust-lang/rust#138672 fixed a query cycle OOM reported in rust-lang/rust#124901. The fix involved delaying computation of some query stack frame elements and was very complex. It involved the addition of two new types, the addition of a generic `I` parameter to eleven(!) other types, a `PhantomData` field, and even required an unsafe transmute of a closure. [This comment](https://github.com/rust-lang/rust/issues/124901#issuecomment-2104852065) had suggested a much simpler fix, but it was ignored. The PR also failed to add a test case.
This PR adds a test case, reverts the complex fix, applies the simpler fix, and does a few other minor cleanups.
r? @oli-obk
Use `default_field_values` more in `Resolver`
Extend more ways of building `FxHashSet`, `FxHashMap`, `UnordSet`, `UnordMap` and `DisambiguatorState` in `const` contexts to allow for more fields in `Resolver` to have a default value. `FxIndexSet`/`FxIndexMap` are still outstanding and not const-buildable.
r? @petrochenkov
simplify words initialization using Rc::new_zeroed
Now that Rc::new_zeroed is stable, remove the cfg(feature = "nightly") branch and the temporary zeroed array on stable. This avoids copying a potentially large [Word; CHUNK_WORDS] into the Rc.
Support primitives in type info reflection
Tracking issue: rust-lang/rust#146922 `#![feature(type_info)]`
This PR supports {`bool`,`char`,`int`,`uint`,`float`,`str`} primitive types for feature `type_info` reflection.
r? @oli-obk
Cache derive proc macro expansion with incremental query
This is a revival of https://github.com/rust-lang/rust/pull/129102, originally implemented by @futile. Since it looks like they are not active currently, I'd like to push this work forward.
The first commit is squashed and rebased work from the original PR, with author attribution to futile. The rest of the commits are some additional comments that I created mostly for myself to understand what happens here. I also did some cleanups based on Vadim's review comments on the original PR, plus I refactored the TLS access a bit using `scoped_tls`.
The biggest issue, as usually, are tests... I tried using `#[rustc_clean(..., loaded_from_disk = "derive_macro_expansion")]`, but the problem is that since this query cannot recover the original key from its hash, and thus its fingerprintstyle is `FingerprintStyle::Opaque`, [this](https://github.com/rust-lang/rust/blob/2fef0a30ae6b2687dfb286cb544d2a542f7e2335/compiler/rustc_incremental/src/persist/dirty_clean.rs#L388) crashes when I try to use `loaded_from_disk`. Any suggestions from someone who actually understands the query system would be welcome 😅
TODO: document the new unstable flag
On a no-op change re-check of `octocrab 0.49` (which has a ton of `serde` derive proc macro invocations), this saves ~0.6s out of ~6s (so a ~10% win) on my PC.
r? @petrochenkov
This PR adds an additional help note to the ambiguity lint error output
to ask users updating their dependencies. This hopefully helps with
cases like https://github.com/rust-lang/rust/issues/149845 where newer crate versions are fixed.
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#151166 (fix: Do not delay E0107 when there exists an assoc ty with the same name)
- rust-lang/rust#151185 (Disable `dump-ice-to-disk` on `i686-pc-windows-msvc`)
r? @ghost
PR #138672 introduced a complex and invasive split of `QueryStackFrame`
to avoid a query cycle. This commit reverts that change because there is
a much simpler change that fixes the problem, which will be in the next
commit.
fix: Do not delay E0107 when there exists an assoc ty with the same name
Fixesrust-lang/rust#148121
When we have the following code:
```rust
trait Foo<T> {}
impl Foo<T: Default> for String {}
```
we delay `E0107: wrong number of generic args` to suggest moving `T: Default` bound to the impl block's param declaration.
The delay is determined by whether all the missing generic parameters are mentioned by those *wrong* assoc item constraints.
But this delay is wrong when there exist any *correct* assoc item constraints, i.e. when we have an assoc type whose identifier is same with a missing generic parameter like in the following code:
```rust
pub trait Super<X> {
type X;
}
pub trait A {}
impl A for dyn Super<X = ()> {}
```
THIR patterns: Always use type `str` for string-constant-value nodes
Historically, constants and literals of type `&str` have been represented in THIR patterns as `PatKind::Const` nodes with type `&str`.
That's fine for stable Rust, but `feature(deref_patterns)` also created a need to have string literal patterns of type `str` in some cases, which resulted in a number of additional special cases and inconsistencies in typechecking and in HIR-to-THIR-to-MIR lowering of patterns.
We can avoid several of those special cases by having THIR treat string-constant-values as fundamentally being of type `str`, and then using `PatKind::Deref` to represent the additional `&` layer in the common case where it is needed. This allows bare `str` patterns to require very little special treatment.
Existing tests should already do a good job of demonstrating that this implementation change does not affect the stable language.
Jonathan Brouwer