Can From* derivations point to meta item's span in error cases?

[TedDriggs]

If I understand some of the proc-macro2 goals correctly, darling should be able to pinpoint the offending term in the input as the span, rather than the name of the macro.

Open Questions

1. Can this be done on stable yet? No. See this
2. Does this require changing the darling::Error interface? Probably. We'd want that interface to support taking an ident or span.
3. Can darling surface multiple errors from a single invocation?

[TedDriggs]

I've found a way to do this that shouldn't break existing usage of darling::Error. I'm going to push a couple commits to master, but I'm not planning to release just yet.

[TedDriggs]

cc @Eijebong as an FYI

[TedDriggs]

Documenting the plan for posterity:

1. Add span property to darling::Error. It's an Option<proc_macro2::Span>; right now there doesn't seem to be much that one can actually do with this without enabling some very unstable APIs, but this is the thing that we should be retaining to know where errors belong.
2. Add with_span function to set the span on an error. This is necessary since most of the trait functions in FromMeta deal with values such as strings, which have their span removed. The function is a no-op if an error already has a span, so this should mean diagnostics will attach to the narrowest possible span.
3. Make the default implementations of from_meta etc. call with_span in the error case. This should cause most hand impls of FromMeta to still behave correctly with no change by the trait implementer.
4. (Maybe necessary?) Make generated impls of FromMeta and FromField call with_span. This should be harmless, since the with_span method safely does nothing if the span was already set lower down.
5. Add util::SpannedValue<T> to let authors get spans with fields in their structs. See Add WithSpan<T> #47 for more details on this. This will be useful for fields that have non-blocking validations on them, such as deprecated proc-macro options.
6. When the diagnostic APIs stabilize, add an emit function to darling::Error which flattens the errors and emits each one as an error-level diagnostic. That should then let someone write something like:

match MyReceiver::from_derive_input(&input) {
    Ok(val) => { /* ... */ },
    Err(e) => { e.emit(); panic!("Diagnostics failed"); }
}

Note that I'm not sure what the macro is supposed to do after emitting diagnostics: Does it just hand back the unmodified token stream?

[TedDriggs]

This came up on reddit; it's likely a barrier to adoption of the library, and should be fixed.

[TedDriggs]

I think this is fixed by the release of v0.8.4