Add field-specific functionality to Into

[MegaBluejay]

Resolves #287

Synopsis

Allow using the same attribute arguments on fields as on the whole struct, generate impls for each

Solution

Extract the common arguments of struct and field attributes into a seperate parser

See details on proposed semantics of using both together in the issue

Checklist

• Documentation is updated (if required)
• Tests are added/updated (if required)
• CHANGELOG entry is added (if required)

[JelteF]

Why are these impls here? If they are there on purpose they could use a code comment.

[MegaBluejay]

The idea was to test that no extra impls get generated, similarly to this IntoIterator test

For instance, no impl should be generated using all the fields if there's at least one field attribute, and if there are types specified in an attribute the field's type shouldn't get one either.

[tyranron]

@MegaBluejay please, read the #287 (comment), where the design was finalized, and consider it.

A case currently not supported is skipping fields for which other arguments are also present, e.g.

#[derive(Into)]
#[into]
struct Foo {
    #[into(skip, String)]
    a: String,
    b: i32
    c: f64,
}

to generate Foo -> (i32, f64) and Foo -> String impls.

This isn't mentioned in the issue, and I'm not sure how useful it would be

This should be definitely supported as separate attributes:

#[derive(Into)]
#[into]
struct Foo {
    #[into(String)]
    #[into(skip)]
    a: String,
    b: i32
    c: f64,
}

[tyranron]

@MegaBluejay please, consider to reuse #303 changes in this PR.

[tyranron]

@MegaBluejay thanks! Overall: good job! 🍻

I've simplified your solution a bit, as introducing generic Alt and Pair structural types encoding just for removing Option merging boilerplate feels a little bit too much. Adding ParseMultiple::merge_opt_attrs() should do the job as good, while keeping less amount of code overall.

@JelteF since this PR introduces new API, please take a look.

Also, after merging this PR, would you be so kind to release 1.0.0-beta.4 version?

[tyranron]

@MegaBluejay if parsing left has failed, we have the broken state on input stream already, so parsing right would likely fail as well. Whenever we try to parse something, we should use .fork()ing to omit changing the initial state of the input stream.

[tyranron]

ping @JelteF

[JelteF]

The new API looks good to me

[JelteF]

I released v1.0.0-beta.6 which includes this change. (cargo release was causing some problems so the beta version was bumped a few times more than intended)