Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#150767 (Allow invoking all help options at once)
- rust-lang/rust#150886 (Added mGCA related tests)
- rust-lang/rust#151245 (Explicitly list crate level attrs)
- rust-lang/rust#151268 (Fix ICE on inconsistent import resolution with macro-attributed extern crate)
- rust-lang/rust#151275 (Normalize type_const items even with feature `generic_const_exprs`)
- rust-lang/rust#151288 (Use `find_attr` instead of `attr::contains_name` in `lower_const_item_rhs`)
- rust-lang/rust#151321 (Port #![no_main] to the attribute parser.)
r? @ghost
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.
Supress some lookup errors if a module contains `compile_error!`
The problem is that when a macro expand to `compile_error!` because its input is malformed, the actual error message from the `compile_error!` might be hidden in a long list of other messages about using items that should have otherwise been generated by the macro.
So suppress error about missing items in that module.
Fixesrust-lang/rust#68838
The problem is that when a macro expand to `compile_error!` because
its input is malformed, the actual error message from the
`compile_error!` might be hidden in a long list of other messages about
using items that should have otherwise been generated by the macro.
So suppress error about missing items in that module.
Fixes issue 68838
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.
Preliminary match/capture test cleanup for PR 150681
Review for rust-lang/rust#150681 requested that this cleanup gets extracted to a separate PR.
r? @Zalathar
Fix deprecated attribute intra-doc link not resolved in the right location on reexported item
Fixes https://github.com/rust-lang/rust/issues/151028.
Follow-up of https://github.com/rust-lang/rust/pull/150721.
So when we resolve an intra-doc link, its current context (the module from which we resolve in short) is very important. However, when we use an intra-doc link in a `#[deprecated]` attribute on a reexported item, we were using the context of the reexported item and not of the `use` itself. Meaning that if you have an intra-doc link `std::mem::drop` on an item from another crate (let's say `core`), then the import will simply fail since there is no `std` dependency.
Now comes the not so funny fix: at this point, we don't know anymore where the attribute came from (ie, from the reexport or from the reexported item) since we already merged the attribute at this point. The solution I found to go around this problem is to check if the item span contains the attribute, and if not, then we use the `inline_stmt_id` as context instead of the item's ID. I'm not super happy and I'm sure we'll find corner cases in the future (like with macros), however there are a few things that mitigate this fix:
1. The only way to generate an attribute with a macro with its item while having different spans is by using proc-macros. In that case, we can always default to the `inline_stmt_id` as context and be fine, but I guess we'll see when get there.
2. It only concerns reexports, so the area of the problem is quite restricted.
Hopefully this explanation made sense. :)
cc @folkertdev
r? @lolbinarycat
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.
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
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](2fef0a30ae/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
Disable `dump-ice-to-disk` on `i686-pc-windows-msvc`
Sometimes the middle frames of the ICE backtrace becomes `<unknown>` on `i686-pc-windows-msvc` which then makes this test flaky. Noticed in https://github.com/rust-lang/rust/pull/150925#issuecomment-3754504924.
Originally expanded in rust-lang/rust#142563 to see if it's still flaky for other `*-windows-*` targets, unfortunately the answer is yes for `i686-pc-windows-msvc` as well.
r? @dianqk (or compiler or anyone really)
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.
Issue #124901 was an OOM caused by a query cycle. It was fixed by
a complex change in PR #138672, but that PR did not add the test case.
Let's add it now, because it's the only known reproducer of the OOM.
