NFC: Provide best practices for errors

[TedDriggs]

This improves the documentation about how best to use darling::Error

[TedDriggs]

@chipsenkbeil can you take a look at this?

[TedDriggs]

@chipsenkbeil correct. darling errors bind to the tightest span they can, so choosing one of them is likely to point to some random field or meta-item, rather than to any usefully-broad span. Using Span::call_site() is the appropriate move for that, though as seen in #110 that will cause the error to point at the macro invocation.

Having looked at entity-rs, I don't see it doing anything that precludes the use of darling::Error for its custom validations after initial parsing. I did see some places where you use the ? operator a function that returns a Result<_, syn::Error>, so I've added a conversion from syn::Error to darling::Error to make that seamless in #116

[chipsenkbeil]

@chipsenkbeil correct. darling errors bind to the tightest span they can, so choosing one of them is likely to point to some random field or meta-item, rather than to any usefully-broad span. Using Span::call_site() is the appropriate move for that, though as seen in #110 that will cause the error to point at the macro invocation.

Having looked at entity-rs, I don't see it doing anything that precludes the use of darling::Error for its custom validations after initial parsing. I did see some places where you use the ? operator a function that returns a Result<_, syn::Error>, so I've added a conversion from syn::Error to darling::Error to make that seamless in #116

I'm planning to do a little refactoring to clean up the code and split out the derive into multiple derives, so I can work on switching over to darling::Error at the same time. Thanks for all of the help and patience!