UX improved error message idea: List valid attribute keys on error

[schneems]

First of, thanks for the crate. Lots of great stuff here. A co-worker suggested I take a look as I've been hand-rolling a lot of proc-macros recently.

One of the things I've done is to list out all possible attribute keys on error, implementation and another.

You can see the output of these implementations in this test.

Hand-rolled output:

Unknown cache_diff attribute: `unknown`. Must be one of `rename`, `display`, `ignore`

Versus darling::FromDeriveInput output:

Unknown field: `unknown`

Through the suggestions feature I see errors like:

>Unknown field: `custommm`. Did you mean `custom`?`

So I'm guessing that there's a minimum threshold for the similarity score. When that's not met, instead of printing nothing, what if we printed all known keywords? Perhaps some people want to limit the number shown, it could be configurable, perhaps something like #[darling(suggest(max_fallback = 8))] to limit the number of attributes show to 8. Then (like the Rust compiler) it could emit ... and N more. To indicate the list isn't exhaustive.

Alternatives: Always list out all valid on failure, even when there's a "did you mean" match.

[TedDriggs]

I am supportive of storing and showing the alternates that are passed to Error::unknown_field_with_alts and Error::unknown_field_path_with_alts.

I would like to keep the "did you mean" when there is an option that is sufficiently close to the observed value, so I'd probably do this by adding a separate field to ErrorUnknownField which keeps the full alternates set.

There are three options for ordering the alternates:

1. Caller-specified order
2. Alphabetical order
3. Similarity order

I'm in favor of alphabetical order: It's stable, hides implementation details of the error's construction, and since we will already have the most-similar option, I doubt ranking by descending similarity will produce a very useful ordering.

I am not in favor of the max_fallback attribute; that would add a lot of code complexity to thread that through, and I don't see a benefit in making it configurable. I'd expect the Display impl to choose a sensible default behavior. I'd be interested to see some examples from other libraries (serde being the most notable) on how this is handled.

Optionally, when the nightly diagnostics feature is enabled, I could see using a child Help-level diagnostic to provide the list of options. In that world, the parent error diagnostic would only contain the "did you mean" suggestion, and the child diagnostic would always provide the full list.