rust/compiler/rustc_trait_selection/src/errors.rs, branch beta

Use `tcx.short_string()` in more diagnostics

2025-08-07T21:18:00+00:00

`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`. We add support for shortening the path of "trait path only". Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem). When we don't actually print out a shortened type we don't need the "use `--verbose`" note. On E0599 show type identity to avoid expanding the receiver's generic parameters. Unify wording on `long_ty_path` everywhere.

parse `const trait Trait`

2025-07-17T10:06:26+00:00

setup CI and tidy to use typos for spellchecking and fix few typos

2025-07-03T07:51:06+00:00

Make E0621 missing lifetime suggestion verbose

2025-06-09T19:55:00+00:00

``` error[E0621]: explicit lifetime required in the type of `x` --> $DIR/42701_one_named_and_one_anonymous.rs:10:9 | LL | &*x | ^^^ lifetime `'a` required | help: add explicit lifetime `'a` to the type of `x` | LL | fn foo2<'a>(a: &'a Foo, x: &'a i32) -> &'a i32 { | ++ ```

Auto merge of #138677 - shepmaster:consistent-elided-lifetime-syntax, r=traviscross,jieyouxu

2025-06-05T19:49:30+00:00

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.

Add `iter` macro

2025-06-03T17:52:32+00:00

This adds an `iter!` macro that can be used to create movable generators. This also adds a yield_expr feature so the `yield` keyword can be used within iter! macro bodies. This was needed because several unstable features each need `yield` expressions, so this allows us to stabilize them separately from any individual feature. Co-authored-by: Oli Scherer Co-authored-by: Jieyou Xu Co-authored-by: Travis Cross

Rename `LifetimeSyntax` variants to lang-team-approved names

2025-06-03T13:06:08+00:00

do away with `_Self` and `TraitName` and check generic params for rustc_on_unimplemented

2025-05-17T13:15:53+00:00

Disarm `time` bomb (diagnostics)

2025-05-09T10:09:15+00:00

Revert "Rollup merge of #129343 - estebank:time-version, r=jieyouxu" This reverts commit 26f75a65d70773e4520634b9f6599ddf08c499e6, reversing changes made to 2572e0e8c9d5d671eccb1d5791e55c929c4720f4. Imports are modified to fix merge conflicts and remove unused ones.

Rollup merge of #140307 - mejrs:condition_parser, r=nnethercote

2025-05-05T04:20:57+00:00

Refactor rustc_on_unimplemented's filter parser Followup to https://github.com/rust-lang/rust/pull/139091; I plan on moving most of this code into `rustc_attr_parsing` at some point, but want to land this separately first. I have taken care to preserve the original behavior as much as I could: - All but one of the new error variants are replacements for the ones originally emitted by the cfg parsing machinery; so these errors are not "new". - the `InvalidFlag` variant is new, this PR turns this (from being ignored and silently doing nothing) into an error: ```rust #[rustc_on_unimplemented(on(something, message = "y"))] //~^ ERROR invalid boolean flag //~^^ NOTE expected one of `crate_local`, `direct` or `from_desugaring`, not `something` trait InvalidFlag {} ``` This does not occur anywhere except in this test. I couldn't find a way that I liked to keep allowing this or to do nothing, erroring was the cleanest solution. - There are a bunch of FIXME throughout this and the previous PR, I plan on addressing those in follow up prs.. Finally, this gets rid of the "longest" dependency in rustc: ![image](https://github.com/user-attachments/assets/3c3eb3a0-b7b3-40d9-aada-a752e28c8678)