Before that fix following code panics, because `Token::Unit` was unexpected by test deserializer:
```
#[derive(Deserialize)]
enum E { ... }
assert_de_tokens_error::<E>(&[Token::Unit], "...");
```
The following changes are included:
- Delete per-file license notices at the top of each file.
- Delete the first paragraph of LICENSE-MIT (an inaccurate
pseudo-copyright line), leaving only the text of the MIT license.
Nothing about the license of Serde code has changed, only our
understanding of how to correctly communicate that license has changed.
This mirrors an equivalent change being applied in the rust-lang/rust
repository.
There are at least two reasonable things to expect the len field to
check: the length of the fields array passed to deserialize_struct, or
the number of field tokens. Even beyond these, in some cases it can be
useful to test deserialization with a bogus len to test how the
Deserialize impl reacts to an incorrect size_hint.
This reverts commit 436cafb0a3 which was
released in serde_test 1.0.20.
The serde_test Serializer and Deserializer panic in is_human_readable unless the
readableness has been set explicitly through one of the hidden functions. This
is to force types that have distinct readable/compact representations to be
tested explicitly in one or the other, rather than with a plain assert_tokens
which arbitrarily picks one.
We need to follow up by designing a better API in serde_test to expose this
publicly. For now serde_test cannot be used to test types that rely on
is_human_readable. (The hidden functions are meant for our test suite only.)
This implements the KISS suggested in https://github.com/serde-rs/serde/issues/790.
It is possible that one of the other approaches may be better but this
seemed like the simplest one to reignite som discussion.
Personally I find the original suggestion of adding two traits perhaps slightly
cleaner in theory but I think it ends up more complicated in the end
since the added traits also need to be duplicated to to the `Seed`
traits.
Closes#790