Commit graph

388 commits

Author SHA1 Message Date
Esteban Küber
c73b3d20c6 Unify wording of resolve error
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".

```
error[E0433]: cannot find `nonexistent` in `existent`
  --> $DIR/custom_attr_multisegment_error.rs:5:13
   |
LL | #[existent::nonexistent]
   |             ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
2026-02-17 16:51:44 +00:00
Ralf Jung
5e65109f21 add write_box_via_move intrinsic and use it for vec!
This allows us to get rid of box_new entirely
2026-02-16 17:27:40 +01:00
Jonathan Brouwer
c61c2603cf Port #[lang] to the new attribute parsers 2026-02-13 16:04:19 +00:00
xizheyin
ed90b35669 Add note when inherent impl for a alias type defined outside of the crate 2026-02-09 15:10:01 +08:00
Jonathan Brouwer
c1091da34c
Fix existing messages in stderrs 2026-02-07 09:13:42 +01:00
Esteban Küber
dffec20dee Tweak help to unify formatting and wording 2026-02-01 18:20:31 +00:00
Esteban Küber
879633f97b Change note to help 2026-02-01 18:20:31 +00:00
Esteban Küber
20000ca25a Point at destructor when denying deriving Copy 2026-02-01 18:20:30 +00:00
Esteban Küber
aebf1fdcf9 Keep span of type in builtin derive macros expansions 2026-02-01 18:20:30 +00:00
Esteban Küber
4a27be6972 Do not mention -Zmacro-backtrace for std macros that are a wrapper around a compiler intrinsic 2026-01-26 17:34:31 +00:00
León Orell Valerian Liehr
233a45c41a
Fix handling of const params defaults that ref Self & generalize diag
We used to lower such bad defaulted const args in trait object types to
`{type error}`; now correctly lower them to `{const error}`.

The added tests used to ICE prior to this change.
2026-01-21 12:53:47 +01:00
León Orell Valerian Liehr
9b861ace46
Generalize diag for missing assoc types to account for assoc consts 2026-01-21 12:53:46 +01:00
Jonathan Brouwer
f5a1fc75ad
Update uitests 2026-01-18 22:41:00 +01:00
Jonathan Brouwer
cbcd1c3eef
Rollup merge of #151036 - issue-151026, r=mati865
Better handle when trying to iterate on a `Range` of a type that isn't `Step`

Mention when a trait bound corresponds to an unstable trait.

Mention `Range` when `Step` bound is unment, and explain that only some std types impl `Iterator` for `Range`.

CC rust-lang/rust#151026
2026-01-14 11:05:40 +01:00
Guillaume Gomez
6c700ecd6a
Rollup merge of #150737 - smithdb3/fix-150576, r=chenyukang
diagnostics: make implicit Sized bounds explicit in E0277

When a trait parameter depends upon Sized, the error message only referred to the full trait itself and didn't mention Sized. This makes the failure to implement Sized explicit. It also notes when the Sized trait bound is explicit or implicit.

Fixes rust-lang/rust#150576
2026-01-13 23:39:08 +01:00
Esteban Küber
cafe91749f On unmet trait bound, mention if trait is unstable 2026-01-13 01:16:58 +00:00
Jakub Beránek
284d1361e4
Dogfood -Zno-embed-metadata for the standard library 2026-01-12 10:52:13 +01:00
Daniel Smith
291d0a9a4b diagnostics: make implicit Sized bounds explicit in E0277
When a trait parameter depends upon Sized, the error message only
referred to the full trait itself and didn't mention Sized. This makes
the failure to implement Sized explicit. It also notes when the Sized
trait bound is explicit or implicit.
2026-01-08 16:07:18 -05:00
Oli Scherer
a3359bdd4f Compile-Time Reflection MVP: tuples 2026-01-08 11:41:00 +00:00
Edvin Bryntesson
acd6ba4edb
Port #[instruction_set] to attribute parser 2025-12-31 03:01:05 +01:00
bors
3f4dc1e02d Auto merge of #146348 - jdonszelmann:eiiv3, r=lcnr,oli-obk
Externally implementable items

Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418

Getting started:

```rust
#![feature(eii)]

#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
    println!("default {x}");
}

// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
    println!("explicit {x}");
}

fn main() {
    decl1(4);
}
```

- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions

This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols

The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
2025-12-14 04:20:26 +00:00
Guillaume Gomez
d025cdef7d If there are too many suggestions for malformed attribute, do not suggest them 2025-12-12 14:55:17 +01:00
Jana Dönszelmann
52e0bfccb0
rename feature gate to extern_item_impls 2025-12-12 11:32:35 +01:00
Jana Dönszelmann
a4abfad99b
EII new error code 2025-12-12 11:32:26 +01:00
bors
bad50269f8 Auto merge of #147602 - JohnTitor:dedup-lifetime-capture-errors, r=estebank
Deduplicate higher-ranked lifetime capture errors in impl Trait

  Previously, when an `impl Trait` captured multiple higher-ranked
  lifetimes from an outer `impl Trait`, the compiler would emit a
  separate error for each captured lifetime. This resulted in verbose
  and confusing diagnostics, especially in edition 2024 where implicit
  captures caused duplicate errors.

  This commit introduces error accumulation that collects all capture
  spans and lifetime declaration spans, then emits a single consolidated
  diagnostic using MultiSpan. The new error shows all captured lifetimes
  with visual indicators and lists all declarations in a single note.

r? `@estebank`
Fixes https://github.com/rust-lang/rust/issues/143022
2025-12-10 06:52:27 +00:00
Matthias Krüger
420ef95cd7
Rollup merge of #149528 - fee1-dead-contrib:rangeboundreword, r=jieyouxu
reword error for invalid range patterns

For half-open ranges, specifies that the upper bound cannot be the minimum.

Also specify that this only applies to range patterns and not also expressions.

Fixes rust-lang/rust#149165
2025-12-04 08:46:21 +01:00
Deadbeef
f8ca417559 reword error for invalid range patterns
For half-open ranges, specifies that the upper bound cannot be the minimum.

Also specify that this only applies to range patterns and not also expressions.
2025-12-02 18:28:05 +00:00
xonx4l
4b000cfacd Merge E0412 into E0425 2025-12-02 18:25:13 +00:00
bors
e6edf3ae53 Auto merge of #147498 - ferrocene:pvdrz/edition-range-gating, r=jieyouxu,fmease
Gate tests with the right edition

This PR guarantees that `./x test --test-args="--edition XXXX" ui` runs correctly with the 2015, 2018 and 2021 editions.

I don't expect this PR to hold up over time but it helps to submit further updates to the `//@ edition` directives of tests where we can use the new range syntax to have a more robust testing across different editions

r? `@fmease`

---

try-job: aarch64-gnu
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: test-various
try-job: armhf-gnu
2025-11-27 22:37:05 +00:00
Christian Poveda
7ae2823bc6
Gate 2018 UI tests 2025-11-27 14:13:58 -05:00
Christian Poveda
b2ab7cf980
Gate 2015 UI tests 2025-11-27 11:19:00 -05:00
lcnr
8e08af1769 fix tooling 2025-11-26 11:09:03 +01:00
lcnr
feb13036ef remove support for type-of 2025-11-25 10:19:44 +01:00
reddevilmidzy
d3e4dd29a8 Use let...else consistently in user-facing diagnostics 2025-11-24 11:41:52 +09:00
Esteban Küber
71b0755a98 Provide more context when mutably borrowing an imutable borrow
Point at statics and consts being mutable borrowed or written to:

```
error[E0594]: cannot assign to immutable static item `NUM`
  --> $DIR/E0594.rs:4:5
   |
LL | static NUM: i32 = 18;
   | --------------- this `static` cannot be written to
...
LL |     NUM = 20;
   |     ^^^^^^^^ cannot assign
```

Point at the expression that couldn't be mutably borrowed from a pattern:

```
error[E0596]: cannot borrow data in a `&` reference as mutable
  --> $DIR/mut-pattern-of-immutable-borrow.rs:19:14
   |
LL |     match &arg.field {
   |           ---------- this cannot be borrowed as mutable
LL |         Some(ref mut s) => s.push('a'),
   |              ^^^^^^^^^ cannot borrow as mutable
```
2025-11-09 22:14:48 +00:00
Esteban Küber
14646ec374 Add note to E0401 2025-11-03 16:24:36 +00:00
Esteban Küber
ba2600e98e Suggest appropriate type instead of Self in E0401
```
error[E0401]: can't use `Self` from outer item
  --> $DIR/E0401.rs:22:25
   |
LL | impl<T> Iterator for A<T> {
   | ---- `Self` type implicitly declared here, by this `impl`
...
LL |         fn helper(sel: &Self) -> u8 {
   |            ------       ^^^^ use of `Self` from outer item
   |            |
   |            `Self` used in this inner function
   |
help: refer to the type directly here instead
   |
LL -         fn helper(sel: &Self) -> u8 {
LL +         fn helper(sel: &A<T>) -> u8 {
   |
```
2025-11-03 16:24:35 +00:00
Stuart Cook
c10e1e4122
Rollup merge of #148370 - estebank:outer-param, r=JonathanBrouwer
Point at inner item when it uses generic type param from outer item or `Self`

Partially address rust-lang/rust#37892.

In E0401 generated in resolve:
```
error[E0401]: can't use generic parameters from outer item
  --> $DIR/E0401.rs:4:39
   |
LL | fn foo<T>(x: T) {
   |        - type parameter from outer item
LL |     fn bfnr<U, V: Baz<U>, W: Fn()>(y: T) {
   |        ----                           ^ use of generic parameter from outer item
   |        |
   |        generic parameter used in this inner function
   |
help: try introducing a local generic parameter here
   |
LL |     fn bfnr<T, U, V: Baz<U>, W: Fn()>(y: T) {
   |             ++
```
In E0401 generated in hir_typeck:
```
error[E0401]: can't reference `Self` constructor from outer item
  --> $DIR/do-not-ice-on-note_and_explain.rs:6:13
   |
LL | impl<B> A<B> {
   | ------------ the inner item doesn't inherit generics from this impl, so `Self` is invalid to reference
LL |     fn d() {
LL |         fn d() {
   |            - `Self` used in this inner item
LL |             Self(1)
   |             ^^^^ help: replace `Self` with the actual type: `A`
```
2025-11-03 11:52:41 +11:00
Esteban Küber
a2c3913007 review comments 2025-11-02 20:12:26 +00:00
Esteban Küber
9bc814cc8d Point at the enclosing const context
```
error[E0015]: cannot call non-const associated function `Foo::{constant#0}::Foo::<17>::value` in constants
  --> $DIR/nested-type.rs:15:5
   |
LL |   struct Foo<const N: [u8; {
   |  __________________________-
LL | |     struct Foo<const N: usize>;
LL | |
LL | |     impl<const N: usize> Foo<N> {
...  |
LL | |     Foo::<17>::value()
   | |     ^^^^^^^^^^^^^^^^^^
LL | |
LL | | }]>;
   | |_- calls in constants are limited to constant functions, tuple structs and tuple variants
```
2025-11-02 20:12:26 +00:00
Esteban Küber
a08bdffb21 Point at non-const trait when using them in const context
Point at trait and associated item when that associated item is used in a const context. Suggest making the trait `#[const_trait]`.

```
error[E0015]: cannot call non-const method `<() as Trait>::foo` in constant functions
  --> $DIR/inline-incorrect-early-bound-in-ctfe.rs:26:8
   |
LL |     ().foo();
   |        ^^^^^
   |
note: method `foo` is not const because trait `Trait` is not const
  --> $DIR/inline-incorrect-early-bound-in-ctfe.rs:13:1
   |
LL | trait Trait {
   | ^^^^^^^^^^^ this trait is not const
LL |     fn foo(self);
   |     ------------- this method is not const
   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants
help: consider making trait `Trait` const
   |
LL + #[const_trait]
LL | trait Trait {
   |
```
2025-11-02 20:12:26 +00:00
Esteban Küber
f6938709c8 Point at inner item when using outer item type param
```
error[E0401]: can't use generic parameters from outer item
  --> $DIR/E0401.rs:4:39
   |
LL | fn foo<T>(x: T) {
   |        - type parameter from outer item
LL |     fn bfnr<U, V: Baz<U>, W: Fn()>(y: T) {
   |        ----                           ^ use of generic parameter from outer item
   |        |
   |        generic parameter used in this inner function
   |
help: try introducing a local generic parameter here
   |
LL |     fn bfnr<T, U, V: Baz<U>, W: Fn()>(y: T) {
   |             ++
```
2025-11-01 18:29:46 +00:00
Esteban Küber
973ab7d08f Make "add param to inner item" suggestion verbose
```
error[E0401]: can't use generic parameters from outer item
  --> $DIR/enum-definition-with-outer-generic-parameter-5997.rs:3:16
   |
LL | fn f<Z>() -> bool {
   |      - type parameter from outer item
LL |     enum E { V(Z) }
   |                ^ use of generic parameter from outer item
   |
help: try introducing a local generic parameter here
   |
LL |     enum E<Z> { V(Z) }
   |           +++
```
2025-11-01 18:23:19 +00:00
Deadbeef
3c6ae00204 Make diagnostics clearer for binop-related errors in foreign crates
Fixes redundant language and bad grammar.
2025-10-18 01:20:25 +00:00
Yuki Okushi
e4194c7075 Deduplicate higher-ranked lifetime capture errors in impl Trait
Previously, when an `impl Trait` captured multiple higher-ranked
  lifetimes from an outer `impl Trait`, the compiler would emit a
  separate error for each captured lifetime. This resulted in verbose
  and confusing diagnostics, especially in edition 2024 where implicit
  captures caused duplicate errors.

  This commit introduces error accumulation that collects all capture
  spans and lifetime declaration spans, then emits a single consolidated
  diagnostic using MultiSpan. The new error shows all captured lifetimes
  with visual indicators and lists all declarations in a single note.
2025-10-12 16:51:28 +09:00
Matthias Krüger
15b7792a65
Rollup merge of #146593 - Jules-Bertholet:restrict-e0719, r=BoxyUwU
Allow specifying multiple bounds for same associated item, except in trait objects

Supersedes https://github.com/rust-lang/rust/pull/143146, fixes https://github.com/rust-lang/rust/issues/143143.

This PR proposes to stop enforcing E0719 in all contexts other than trait object types.

E0719 forbids constraining the same associated item twice within the same angle-bracket delimited associated item bound list (the `…` inside `T: Trait<…>`). For example, the following are forbidden:

| Forbidden                                  | Working alternative                                                |
|--------------------------------------------|--------------------------------------------------------------------|
| `T: Trait<Gat<u32> = u32, Gat<u64> = u64>` | `T: Trait<Gat<u32> = u32> + Trait<Gat<u64> = u64>`                 |
| `T: Iterator<Item = u32, Item = i32>`      | `T: Iterator<Item = u32> + Iterator<Item = i32>` (trivially false) |
| `T: Iterator<Item = u32, Item = u32>`      | `T: Iterator<Item = u32>`                                          |
| `T: Iterator<Item: Send, Item: Sync>`      | `T: Iterator<Item: Send + Sync>`                                   |
| `T: Trait<ASSOC = 3, ASSOC = 4>`           | `T: Trait<ASSOC = 3> + Trait<ASSOC = 4>` (trivially false)         |
| `T: Trait<ASSOC = 3, ASSOC = 3>`           | `T: Trait<ASSOC = 3>`                                              |

With this PR, all those previously forbidden examples would start working, as well as their APIT and RPIT equivalents.

Types like `dyn Iterator<Item = u32, Item = u32>` will continue to be rejected, however. See https://github.com/rust-lang/rust/pull/143146#issuecomment-3274421752 for the reason why.

```@rustbot``` label T-lang T-types needs-fcp
2025-10-01 18:42:34 +02:00
Esteban Küber
eceb48534a Make replacement suggestion _ in type verbose
```
error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types
  --> $DIR/in-signature.rs:6:21
   |
LL | fn arr_fn() -> [u8; _] {
   |                     ^ not allowed in type signatures
   |
help: replace with the correct return type
   |
LL - fn arr_fn() -> [u8; _] {
LL + fn arr_fn() -> [u8; 3] {
   |
```
2025-09-29 03:28:52 +00:00
Jules Bertholet
389907a17e
Enforce E0719 only for trait aliases 2025-09-18 09:16:58 -04:00
Jonathan Brouwer
7db1840569
Changes to the uitests
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-08-27 20:25:18 +02:00
Jonathan Brouwer
4bb7bf64e0
Update uitests
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-08-14 18:18:42 +02:00