Implement default_overrides_default_fields lint

[estebank]

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)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

r? @compiler-errors

This is a simpler version of #134441, detecting the simpler case when a field with a default should have not been specified in the manual Default::default(), instead using .. for it. It doesn't provide any suggestions, nor the checks for "equivalences" nor whether the value used in the imp being used would be suitable as a default field value.

[compiler-errors]

One question about this data based approach -- what happens when we have a nested body that is a fn? Something like:

impl Default for Ty {
  fn default() {
    fn other_body() -> Ty {
      Ty { /* override a default struct field or something, idk come up with a way to trigger the lint */ }
    }
  }
}

Might need some tweaking but I think you know what I mean.

---

If this does in fact end up triggering check_body for the wrong body because of the hairy recursive state tracking, it may be better just to inline this logic into the check_impl_item function.

It should be possible to get the hir body by just matching on the ImplItemKind::Fn(_, body_id) to get the id, then calling tcx.hir.body(body_id).

It actually may be beneficial to do this rather than deferring to the check_body function just to make this code simpler.

[compiler-errors]

That is, rather than trying to split it across two functions and letting the lint infrastructure access the body for you, just access the body for yourself and make all of this live inside of one function.

[estebank]

Changing that would make us go counter to #134441 (comment) (use cx.typeck_results()) because then the LateContext doesn't have an enclosed_body yet, and we can't change it because that falls under the LateContextAndPass responsibility (in rustc_lint/src/late.rs). I can either go back to using cx.tcx.has_typeck_results(expr.hir_id.owner.def_id) or impl my own hir::Visitor, making the lint much more... non-standard.

Edit: Wait in this iteration of the lint we no longer look at the expression types. Disregard, there's no need for that here then and can easily fulfill your request without further input.

Edit 2: it should be easier to follow now.

[compiler-errors]

Well, you don't need to go back to using cx.tcx.has_typeck_results(expr.hir_id.owner.def_id). Just call tcx.typeck(def_id) for the item you have.

[compiler-errors]

r=me after perf is complete

@bors try @rust-timer queue

[bors]

⌛ Trying commit 01307cf with merge 43adf23...

[bors]

☀️ Try build successful - checks-actions
Build commit: 43adf23 (43adf23ea96a8aa28d70f3d15f1b9a3f613ec9c6)

[rust-timer]

Finished benchmarking commit (43adf23): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.8%, secondary 1.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.8%	[1.8%, 1.8%]	1
Regressions ❌ (secondary)	1.5%	[1.5%, 1.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.8%	[1.8%, 1.8%]	1

Cycles

Results (secondary -7.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-7.9%	[-8.3%, -7.5%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 765.683s -> 765.294s (-0.05%)
Artifact size: 330.53 MiB -> 330.44 MiB (-0.03%)

[compiler-errors]

@bors r+ rollup=maybe

[bors]

📌 Commit 01307cf has been approved by compiler-errors

It is now in the queue for this repository.