rust/tests/ui/deriving, branch auto

Avoid using `()` in `derive(From)` output.

2025-08-19T08:16:57+00:00

Using an error type instead of `()` avoids the duplicated errors on `struct SUnsizedField` in `deriving-from-wrong-target.rs`. It also improves the expanded output from this: ``` struct S2(u32, u32); impl ::core::convert::From<()> for S2 { #[inline] fn from(value: ()) -> S2 { (/*ERROR*/) } } ``` to this: ``` struct S2(u32, u32); impl ::core::convert::From<(/*ERROR*/)> for S2 { #[inline] fn from(value: (/*ERROR*/)) -> S2 { (/*ERROR*/) } } ``` The new code also only matchs on `item.kind` once.

Remove the `From` derive macro from prelude

2025-08-18T11:12:19+00:00

To avoid backwards compatibility problems.

Implement `#[derive(From)]`

2025-08-15T10:07:15+00:00

expand: Micro-optimize prelude injection

2025-07-28T14:35:09+00:00

Use `splice` to avoid shifting the other items twice. Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.

Rollup merge of #141724 - Sol-Ell:issue-141141-fix, r=nnethercote

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

fix(#141141): When expanding `PartialEq`, check equality of scalar types first. Fixes rust-lang/rust#141141. Now, `cs_eq` function of `partial_eq.rs` compares [scalar types](https://doc.rust-lang.org/rust-by-example/primitives.html#scalar-types) first. - Add `is_scalar` field to `FieldInfo`. - Add `is_scalar` method to `TyKind`. - Pass `FieldInfo` via `CsFold::Combine` and refactor code relying on it. - Implement `TryFrom<&str>` and `TryFrom` for FloatTy. - Implement `TryFrom<&str>` and `TryFrom` for IntTy. - Implement `TryFrom<&str>` and `TryFrom` for UintTy.

Separately check equality of the scalar types and compound types in the order of declaration.

2025-06-02T12:29:34+00:00

Refactor the two-phase check for impls and impl items

2025-05-27T14:03:21+00:00

Remove let_chains feature gate from even more tests

2025-04-18T13:57:29+00:00

Explicitly annotate edition for `unpretty=expanded` and `unpretty=hir` tests

2025-04-16T09:10:10+00:00

These emit prelude imports which means they are always edition dependent

Do not suggest using `-Zmacro-backtrace` for builtin macros

2025-03-14T19:50:03+00:00

For macros that are implemented on the compiler, we do *not* mention the `-Zmacro-backtrace` flag. This includes `derive`s and standard macros.