The proc-macro-error crate is end-of-life and unmaintained #854
Comments
|
Yes, I have been aware of this quite a long time (in fact ever since the |
|
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 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 😄 . |
|
I noticed two things while looking over the code:
I thought about introducing some But of course there's no obvious way to thread such a Context object through the various layers, because of This way the error refactor should become much smaller and the |
Missing migration from `ToResponse`, `IntoResponses`, `axum_extras` and `rocket_extras`. Resolves #854
|
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 To elaborate further I have introduced |
Missing migration from `ToResponse`, `IntoResponses`, `axum_extras` and `rocket_extras`. Resolves #854
Missing migration from `components`, `axum_extras` and `rocket_extras`. Resolves #854
Missing migration from `axum_extras` and `rocket_extras`. Resolves #854
Implement `Result<T, E>` based proc macro error handling instead of out of fashion `proc_macro_error` that still is in _syn_ `1.0`. This allows us to remove the need for `proc_macro_error` crate and makes our dependency tree leaner. The error handling is implemented with custom `ToTokensDiagnostics` trait that is used instead of the `ToTokens` when there is a possibility for error. Error is passed up in the call stack via `Diagnostics` struct that converts to compile error token stream at root of the macro call. The result based approach is the recommended way of handling compile errors in proc macros. Resolves #854
Implement `Result<T, E>` based proc macro error handling instead of out of fashion `proc_macro_error` that still is in _syn_ `1.0`. This allows us to remove the need for `proc_macro_error` crate and makes our dependency tree leaner. The error handling is implemented with custom `ToTokensDiagnostics` trait that is used instead of the `ToTokens` when there is a possibility for error. Error is passed up in the call stack via `Diagnostics` struct that converts to compile error token stream at root of the macro call. The result based approach is the recommended way of handling compile errors in proc macros. Resolves #854
Implement `Result<T, E>` based proc macro error handling instead of out of fashion `proc_macro_error` that still is in _syn_ `1.0`. This allows us to remove the need for `proc_macro_error` crate and makes our dependency tree leaner. The error handling is implemented with custom `ToTokensDiagnostics` trait that is used instead of the `ToTokens` when there is a possibility for error. Error is passed up in the call stack via `Diagnostics` struct that converts to compile error token stream at root of the macro call. The result based approach is the recommended way of handling compile errors in proc macros. Resolves #854
Implement `Result<T, E>` based proc macro error handling instead of out of fashion `proc_macro_error` that still is in _syn_ `1.0`. This allows us to remove the need for `proc_macro_error` crate and makes our dependency tree leaner. The error handling is implemented with custom `ToTokensDiagnostics` trait that is used instead of the `ToTokens` when there is a possibility for error. Error is passed up in the call stack via `Diagnostics` struct that converts to compile error token stream at root of the macro call. The result based approach is the recommended way of handling compile errors in proc macros. Resolves #854
Implement `Result<T, E>` based proc macro error handling instead of out of fashion `proc_macro_error` that still is in _syn_ `1.0`. This allows us to remove the need for `proc_macro_error` crate and makes our dependency tree leaner. The error handling is implemented with custom `ToTokensDiagnostics` trait that is used instead of the `ToTokens` when there is a possibility for error. Error is passed up in the call stack via `Diagnostics` struct that converts to compile error token stream at root of the macro call. The result based approach is the recommended way of handling compile errors in proc macros. Resolves #854
Implement `Result<T, E>` based proc macro error handling instead of out of fashion `proc_macro_error` that still is in _syn_ `1.0`. This allows us to remove the need for `proc_macro_error` crate and makes our dependency tree leaner. The error handling is implemented with custom `ToTokensDiagnostics` trait that is used instead of the `ToTokens` when there is a possibility for error. Error is passed up in the call stack via `Diagnostics` struct that converts to compile error token stream at root of the macro call. The result based approach is the recommended way of handling compile errors in proc macros. Resolves #854
utoipa-genhas migrated tosyn 2.x, but it has proc-macro-error as a dependency which still requiressyn 1.0. This is the last crate in one of my Cargo.locks that requires it.As can be seen on
proc-macro-errors gitlab repo, it looks rather unmaintained, and an update can't be expected. This open gitlab Merge Request talks about various options for migration to other proc-macro diagnostics solutions.After a quick look, it looks like utoipa-gen uses the
abort!()strategy a lot for diagnostic reporting. This pattern seems to have gone out of fashion when I look at the alternatives to proc-macro-error, they seem to propose using aResult-based pattern instead, propagating up to the root macro function.The text was updated successfully, but these errors were encountered: