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.
rustc_resolve: Improve `resolve_const_param_in_non_trivial_anon_const` wording
In some contexts, const expressions are OK. Add a `here` to the error message to clarify this.
Closesrust-lang/rust#79429 which has 15 x 👍
Verbose suggestion to make param `const`
```
error[E0747]: type provided when a constant was expected
--> $DIR/invalid-const-arguments.rs:10:19
|
LL | impl<N> Foo for B<N> {}
| ^
|
help: consider changing this type parameter to a const parameter
|
LL - impl<N> Foo for B<N> {}
LL + impl<const N: u8> Foo for B<N> {}
|
```
Part of rust-lang/rust#141973.
Add a new `mismatched-lifetime-syntaxes` lint
The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](https://github.com/rust-lang/rust/pull/120808#issuecomment-2701863833) their decision. The summary-of-the-summary is:
- Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](https://github.com/rust-lang/rust/issues/48686)! Some examples:
```rust
// Lint will warn about these
fn(v: ContainsLifetime) -> ContainsLifetime<'_>;
fn(&'static u8) -> &u8;
```
- Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule:
```rust
// Lint will not warn about these
fn(&u8) -> &'_ u8;
fn(&'_ u8) -> &u8;
fn(&u8) -> ContainsLifetime<'_>;
```
- Having a lint for consistent syntax of elided lifetimes will make the [future goal](https://github.com/rust-lang/rust/issues/91639) of warning-by-default for paths participating in elision much simpler.
---
This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
```
error[E0747]: type provided when a constant was expected
--> $DIR/invalid-const-arguments.rs:10:19
|
LL | impl<N> Foo for B<N> {}
| ^
|
help: consider changing this type parameter to a const parameter
|
LL - impl<N> Foo for B<N> {}
LL + impl<const N: u8> Foo for B<N> {}
|
```
Defer evaluating type system constants when they use infers or params
Split out of #137972, the parts necessary for associated const equality and min generic const args to make progress and have correct semantics around when CTFE is invoked. According to a [previous perf run](https://perf.rust-lang.org/compare.html?start=93257e2d20809d82d1bc0fcc1942480d1a66d7cd&end=01b4cbf0f47c3f782330db88fa5ba199bba1f8a2&stat=instructions:u) of adding the new `const_arg_kind` query we should expect minor regressions here.
I think this is acceptable as we should be able to remove this query relatively soon once mgca is more complete as we'll then be able to implement GCE in terms of mgca and rip out `GCEConst` at which point it's trivial to determine what kind of anon const we're dealing with (either it has generics and is a repeat expr hack, or it doesnt and is a normal anon const).
This should only affect unstable code as we handle repeat exprs specially and those are the only kinds of type system consts that are allowed to make use of generic parameters.
Fixes#133066Fixes#133199Fixes#136894Fixes#137813
r? compiler-errors
Don't FCW assoc consts in patterns
Fixes#140447
See comment in added test. We could also check that the anon const is a const arg by looking at the HIR. I'm not sure that's necessary though 🤔 The only consts that are evaluated "for the type system" are const args (which *should* get FCWs) and const patterns (which cant be anon consts afaik).
Add regression test for #127424
Fixes: https://github.com/rust-lang/rust/issues/127424
This ICE no longer reproduces, so it appears to have already been fixed.
This PR adds a regression test to ensure the issue doesn’t come back in the future.
Please let me know if there's anything I should improve or revise!
UI tests: add missing diagnostic kinds where possible
The subset of https://github.com/rust-lang/rust/pull/139427 that only adds diagnostic kinds to line annotations, without changing any other things in annotations or compiletest.
After this only non-viral `NOTE`s and `HELP`s should be missing.
r? `@jieyouxu`
Enforce type of const param correctly in MIR typeck
Properly intercepts and then annotates the type for a `ConstKind::Param` in the MIR.
This code should probably be cleaned up, it's kinda spaghetti, but no better structure really occurred to me when writing this case.
We could probably gate this behind the feature gate or add a fast path when the args have no free regions if perf is bad.
r? `@BoxyUwU`
Rollup of 10 pull requests
Successful merges:
- #137715 (Allow int literals for pattern types with int base types)
- #138002 (Disable CFI for weakly linked syscalls)
- #138051 (Add support for downloading GCC from CI)
- #138231 (Prevent ICE in autodiff validation by emitting user-friendly errors)
- #138245 (stabilize `ci_rustc_if_unchanged_logic` test for local environments)
- #138256 (Do not feed anon const a type that references generics that it does not have)
- #138284 (Do not write user type annotation for const param value path)
- #138296 (Remove `AdtFlags::IS_ANONYMOUS` and `Copy`/`Clone` condition for anonymous ADT)
- #138352 (miri native_calls: ensure we actually expose *mutable* provenance to the memory FFI can access)
- #138354 (remove redundant `body` arguments)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not write user type annotation for const param value path
As I noted in the code comment, `DefKind::ConstParam` isn't actually *generic* over its own args, we just use the identity args from the body when lowering the value path so we have something to plug into the `EarlyBinder` we get back from `type_of` for the const param. So skip over it in `write_user_type_annotation_from_args`.
Somewhat unrelated, but I left an explanation for a somewhat mysterious quirk in the THIR lowering of user type annotations for patterns having to do with ctors and their `type_of` not actually being the type of the pattern node it's ascribing.
Fixes#138048
r? ``@BoxyUwU``
