Improve deserialization errors of untagged enums

[dtolnay]

What does this PR try to resolve?

# .cargo/config.toml

[http]
ssl-version.min = false

Before:

$ cargo check
error: data did not match any variant of untagged enum SslVersionConfig

After:

$ cargo check
error: error in /path/to/.cargo/config.toml: could not load config key `http.ssl-version`

Caused by:
  error in /path/to/.cargo/config.toml: `http.ssl-version.min` expected a string, but found a boolean

How should we test and review this PR?

The first commit adds tests showing the pre-existing error messages — mostly just "data did not match any variant of untagged enum T" with no location information. The second commit replaces all #[derive(Deserialize)] #[serde(untagged)] with Deserialize impls based on https://docs.rs/serde-untagged/0.1, showing the effect on the error messages.

Tested with cargo test, and by handwriting some bad .cargo/config.toml files and looking at the error produced by rust-lang/cargo/target/release/cargo check.

[rustbot]

r? @ehuss

(rustbot has picked a reviewer for you, use r? to override)

[epage]

Thanks! I'm assuming this will also offer some (slight) performance improvements based on my own profiling with untagged.

@bors r+

Any thoughts on adding derive support for this?

[bors]

📌 Commit 3871aec has been approved by epage

It is now in the queue for this repository.

[bors]

⌛ Testing commit 3871aec with merge 97e73c7...

[dtolnay]

Yeah we could potentially add derive support by having the call site tag the type of each of the variants.

pub enum SslVersionConfig {
    #[serde(string)]
    Single(String),
    #[serde(map)]
    Range(SslVersionConfigRange),
}

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing 97e73c7 to master...