Allow `#[diagnostic::on_unimplemented]` on `impl`s, specially inherent `impl`s

[estebank]

While working on a derived builder using const params to track fields being set/unset, I noticed that it would be useful to be able to customize the output to explain in users' terms why the method isn't being found:

error[E0599]: no method named `build` found for struct `PartialTest<false, true>` in the current scope
  --> tests/no_compile/missing_fields_in_builder.rs:13:33
   |
 3 | #[bitfield(u32, default = 0, forbid_overlaps)]
   | ---------------------------------------------- method `build` not found for this struct
...
13 |     Test::builder().with_bar(1).build();
   |                                 ^^^^^ method not found in `PartialTest<false, true>`
   |
   = note: the method was found for
           - `PartialTest<true, true>`

error[E0599]: no method named `with_bar` found for struct `PartialTest<true, true>` in the current scope
  --> tests/no_compile/missing_fields_in_builder.rs:15:45
   |
 3 | #[bitfield(u32, default = 0, forbid_overlaps)]
   | ---------------------------------------------- method `with_bar` not found for this struct
...
15 |     Test::builder().with_bar(1).with_foo(1).with_bar(2).build();
   |                                             ^^^^^^^^ method not found in `PartialTest<true, true>`
   |
   = note: the method was found for
           - `PartialTest<foo, false>`
help: one of the expressions' fields has a method of the same name
   |
15 |     Test::builder().with_bar(1).with_foo(1).value.with_bar(2).build();
   |                                             ++++++

A slightly better output with customization could be:

error[E0599]: all fields must be initialized before `Test` can be built
  --> tests/no_compile/missing_fields_in_builder.rs:13:33
   |
 3 | #[bitfield(u32, default = 0, forbid_overlaps)]
   | ---------------------------------------------- method `build` not found for this struct
...
13 |     Test::builder().with_bar(1).build();
   |                                 ^^^^^ method not found in `PartialTest<false, true>`
   |
   = note: no method named `build` found for struct `PartialTest<false, true>` in the current scope
   = note: the method was found for
           - `PartialTest<true, true>`

error[E0599]: the same field can't be set twice
  --> tests/no_compile/missing_fields_in_builder.rs:15:45
   |
 3 | #[bitfield(u32, default = 0, forbid_overlaps)]
   | ---------------------------------------------- method `with_bar` not found for this struct
...
15 |     Test::builder().with_bar(1).with_foo(1).with_bar(2).build();
   |                                             ^^^^^^^^ method can't be called twice
   |
   = note: no method named `with_bar` found for struct `PartialTest<true, true>` in the current scope
   = note: method not found in `PartialTest<true, true>`
   = note: the method was found for
           - `PartialTest<foo, false>`
help: one of the expressions' fields has a method of the same name
   |
15 |     Test::builder().with_bar(1).with_foo(1).value.with_bar(2).build();
   |                                             ++++++

This could be accomplished with:

#[diagnostic::on_unimplemented(message = "all fields must be initialized before `Test` can be built")]
impl PartialTest<true, true> {
    fn build(self) -> Test { .. }
}
#[diagnostic::on_unimplemented(message = "the same field can't be set twice", label = "method can't be called twice")]
impl<const foo: bool> PartialTest<foo, false> {
    fn with_bar(self) -> PartialTest<foo, true> { .. }
}

Ideally, it would be the following, but giving enough hooks to allow for it might be too much:

error[E0599]: all fields must be initialized before `Test` can be built
  --> tests/no_compile/missing_fields_in_builder.rs:13:33
   |
13 |     Test::builder().with_bar(1).build();
   |                                 ^^^^^ `foo` wasn't initalized
   |
   = note: method `with_foo` must be called on the builder first

error[E0599]: the same field can't be set twice
  --> tests/no_compile/missing_fields_in_builder.rs:15:45
   |
15 |     Test::builder().with_bar(1).with_foo(1).with_bar(2).build();
   |                                             ^^^^^^^^ method can't be called twice

but the API to accomplish that could get unwieldy

#[diagnostic::on_unimplemented(
    message = "all fields must be initialized before `Test` can be built",
    on(Self = "PartialTest<true, false>", label = "`foo` wasn't initialized"),
    on(Self = "PartialTest<false, true>", label = "`bar` wasn't initialized"),
    on(Self = "PartialTest<false, false>", label = "`foo` and `bar` weren't initialized"),
    drop_original_message,
    drop_original_label,
    drop_found_list,
    dont_point_at_type
)]
impl PartialTest<true, true> {
    fn build(self) -> Test { .. }
}
#[diagnostic::on_unimplemented(
    message = "the same field can't be set twice",
    label = "method can't be called twice",
    drop_original_message,
    drop_original_label,
    drop_found_list,
    dont_suggest,
    dont_point_at_type
)]
impl<const foo: bool> PartialTest<foo, false> {
    fn with_bar(self) -> PartialTest<foo, true> { .. }
}

Some of this customization could be accomplished by creating a trait for each builder and annotating those, but that would be an arbitrary restriction of the diagnostic machinery, which would also cause projects to pay additional compilation cost purely to customize the diagnostics.

[rperier]

There is currently a task for porting the existing diagnostics attributes (all [diagnostic::*]) to rustc_attr_parsing. One for ::unimplemented is WIP, we should probably wait for it, ihmo (the code will be a lot simpler). see #151558

[mejrs]

I would like to expand the attribute like this in the future (like rperier mentions, blocked by some things).

However I don't like rustc_on_unimplemented's filtering api; that needs some design work.

Some of this customization could be accomplished by creating a trait for each builder and annotating those, but that would be an arbitrary restriction of the diagnostic machinery

I also don't like this; I've seen people invent new traits just to use diagnostic::on_unimplemented. Ideally the api is designed so you can just use the attribute and don't feel like you have to write more code (invent traits, types etc) to do things.