The proc-macro-error crate is end-of-life and unmaintained about utoipa HOT 5 CLOSED

Maybe I'll try soon-ish to make some PRs. I can try to do things in smaller steps. If you want. The kanban board looks full of tasks!

from utoipa.

Maybe I'll try soon-ish to make some PRs. I can try to do things in smaller steps. If you want. The kanban board looks full of tasks!

Thanks, probably it is good to start form something related to ToSchema. 🤔 Or perhaps the OpenApi macro is the smallest one of them so that could be the easiest one of them to migrate.

It is 😓 I haven't had the energy to invest into this library for some time thus it has been outcasting for a while. I have been considering creating an organization page for this so it would be easier for people to work on a patch for the utoipa project. And of course a dedicated group of volunteers would help too 😄 .

from utoipa.

Yes, I have been aware of this quite a long time (in fact ever since the syn 2). I have been pondering with the option going for the Result based error reporting for the proc macros and the syn crate also provides the primitives for that. The problem is that utoipa-gen is quite heavily invested into proc-macro-error and the update will be quite tedious to do, but should be done though.

from utoipa.

I noticed two things while looking over the code:

1. Relying on abort (or "giving up" on the first encountered error in any other way) will only report one error to the user, but there may be several problems reported in the same macro invocation, because utoipa macro inputs can be quite large with several unrelated problems.
2. A lot of try-like things are done from within quote::ToToken impls. I don't think that trait is designed to work with fallible conversion to tokens.

I thought about introducing some &mut Context that can accumulate different errors and report all of them together as a fix for the first point. Error handling for different parts of the macro could then stay more local in their respective modules; at a higher level, the macro can just continue to run even if errors were previously reported.

But of course there's no obvious way to thread such a Context object through the various layers, because of ToTokens and its fixed signature. The next idea is to use some thread_local! that is initialized at the start of each macro, through a trampoline function which checks if there are errors after its inner function has finished executing. If the error list is non-empty it will output a generated compile_error!, otherwise it will output the produced TokenStream.

This way the error refactor should become much smaller and the ToTokens architecture can stay. What do you think @juhaku ?

from utoipa.

You are right about that the first error will only be reported at time. It would most likely make sense to report are errors simultaneously compared to the one at the time. This way user could react to multiple errors in one go. Yet some errors are only available after some other condition happens. It might not be a bad idea to use some sort of thread local or perhaps just some once cell variant to store the errors from one row and then print them out.

I have now done a minimal changes to the architecture to support fallible ToTokens, like you mentioned it is not designed to be fallible.

To elaborate further I have introduced ToTokensDiagnostics (named as so far, probably I will change that name later) that is syntax wise identical to the ToTokens but instead of void it will return Result<(), Diagnostics> that then is propagated up in the call stack to the main function.

from utoipa.