about summary refs log tree commit diff
path: root/compiler/rustc_lint/src/default_could_be_derived.rs
AgeCommit message (Collapse)AuthorLines
2025-08-08Reduce indirect assoc parent queriesCameron Steffen-2/+1
2025-07-31remove rustc_attr_data_structuresJana Dönszelmann-1/+2
2025-07-12Port `#[automatically_derived]` to the new attribute parsing infrastructureJonathan Brouwer-1/+2
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-03setup CI and tidy to use typos for spellchecking and fix few typosklensy-1/+1
2025-05-30Reorder fields in `hir::ItemKind` variants.Nicholas Nethercote-1/+1
Specifically `TyAlias`, `Enum`, `Struct`, `Union`. So the fields match the textual order in the source code. The interesting part of the change is in `compiler/rustc_hir/src/hir.rs`. The rest is extremely mechanical refactoring.
2025-03-18Move `hir::Item::ident` into `hir::ItemKind`.Nicholas Nethercote-1/+5
`hir::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Macro`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, Trait`, TraitAalis`. - It's always empty for these item kinds: `ForeignMod`, `GlobalAsm`, `Impl`. - For `Use`, it is non-empty for `UseKind::Single` and empty for `UseKind::{Glob,ListStem}`. All of this is quite non-obvious; the only documentation is a single comment saying "The name might be a dummy name in case of anonymous items". Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - A similar transformation makes sense for `ast::Item`, but this is already a big change. That can be done later. - Lots of assertions are added to item lowering to ensure that identifiers are empty/non-empty as expected. These will be removable when `ast::Item` is done later. - `ItemKind::Use` doesn't get an `Ident`, but `UseKind::Single` does. - `lower_use_tree` is significantly simpler. No more confusing `&mut Ident` to deal with. - `ItemKind::ident` is a new method, it returns an `Option<Ident>`. It's used with `unwrap` in a few places; sometimes it's hard to tell exactly which item kinds might occur. None of these unwraps fail on the test suite. It's conceivable that some might fail on alternative input. We can deal with those if/when they happen. - In `trait_path` the `find_map`/`if let` is replaced with a loop, and things end up much clearer that way. - `named_span` no longer checks for an empty name; instead the call site now checks for a missing identifier if necessary. - `maybe_inline_local` doesn't need the `glob` argument, it can be computed in-function from the `renamed` argument. - `arbitrary_source_item_ordering::check_mod` had a big `if` statement that was just getting the ident from the item kinds that had one. It could be mostly replaced by a single call to the new `ItemKind::ident` method. - `ItemKind` grows from 56 to 64 bytes, but `Item` stays the same size, and that's what matters, because `ItemKind` only occurs within `Item`.
2025-03-09chore: Fix some commentsStevenMia-1/+1
Signed-off-by: StevenMia <flite@foxmail.com>
2025-02-17Move some `Map` methods onto `TyCtxt`.Nicholas Nethercote-5/+3
The end goal is to eliminate `Map` altogether. I added a `hir_` prefix to all of them, that seemed simplest. The exceptions are `module_items` which became `hir_module_free_items` because there was already a `hir_module_items`, and `items` which became `hir_free_items` for consistency with `hir_module_free_items`.
2024-12-31Provide structured suggestion for `impl Default` of type where all fields ↵Esteban Küber-8/+26
have defaults ``` error: `Default` impl doesn't use the declared default field values --> $DIR/manual-default-impl-could-be-derived.rs:28:1 | LL | / impl Default for B { LL | | fn default() -> Self { LL | | B { LL | | x: s(), | | --- this field has a default value LL | | y: 0, | | - this field has a default value ... | LL | | } | |_^ | help: to avoid divergence in behavior between `Struct { .. }` and `<Struct as Default>::default()`, derive the `Default` | LL ~ #[derive(Default)] struct B { | ``` Note that above the structured suggestion also includes completely removing the manual `impl`, but the rendering doesn't.
2024-12-25Implement `default_overrides_default_fields` lintEsteban Küber-0/+185
Detect when a manual `Default` implementation isn't using the existing default field values and suggest using `..` instead: ``` error: `Default` impl doesn't use the declared default field values --> $DIR/manual-default-impl-could-be-derived.rs:14:1 | LL | / impl Default for A { LL | | fn default() -> Self { LL | | A { LL | | y: 0, | | - this field has a default value ... | LL | | } | |_^ | = help: use the default values in the `impl` with `Struct { mandatory_field, .. }` to avoid them diverging over time note: the lint level is defined here --> $DIR/manual-default-impl-could-be-derived.rs:5:9 | LL | #![deny(default_overrides_default_fields)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ```