Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scylla-macros: report errors as compile errors, not panics #818

Merged
merged 1 commit into from Oct 5, 2023

Conversation

piodul
Copy link
Collaborator

@piodul piodul commented Sep 28, 2023

Our current procedural macros handle errors by panicking. This leads to compilation errors which inform the user about that fact first, and then explain the real issue in the "help" part:

error: proc-macro derive panicked
 --> examples/user-defined-type.rs:6:10
  |
6 | #[derive(FromUserType)]
  |          ^^^^^^^^^^^^
  |
  = help: message: derive(FromUserType) works only on structs!

This commit gets rid of .expect() and panic() calls. Instead, errors are now propagated via Result<T, syn::Error> and properly converted to a compilation error at the end. This approach results in nicer error messages and allows to attach the message to a particular part of the original code that could cause the problem.

After the changes, error messages look like this:

error: derive(FromUserType) works only for structs with named fields
 --> examples/user-defined-type.rs:7:1
  |
7 | enum Foo {
  | ^^^^

Pre-review checklist

  • I have split my patch into logically separate commits.
  • All commit messages clearly explain what they change and why.
  • I added relevant tests for new features and bug fixes.
  • All commits compile, pass static checks and pass test.
  • PR description sums up the changes and reasons why they should be introduced.
  • I have provided docstrings for the public items that I want to introduce.
  • I have adjusted the documentation in ./docs/source/.
  • I added appropriate Fixes: annotations to PR description.

Our current procedural macros handle errors by panicking. This leads to
compilation errors which inform the user about that fact first, and then
explain the real issue in the "help" part:

```
error: proc-macro derive panicked
 --> examples/user-defined-type.rs:6:10
  |
6 | #[derive(FromUserType)]
  |          ^^^^^^^^^^^^
  |
  = help: message: derive(FromUserType) works only on structs!
```

This commit gets rid of `.expect()` and `panic()` calls. Instead, errors
are now propagated via `Result<T, syn::Error>` and properly converted to
a compilation error at the end. This approach results in nicer error
messages and allows to attach the message to a particular part of the
original code that could cause the problem.

After the changes, error messages look like this:

```
error: derive(FromUserType) works only for structs with named fields
 --> examples/user-defined-type.rs:7:1
  |
7 | enum Foo {
  | ^^^^
```
@piodul
Copy link
Collaborator Author

piodul commented Oct 3, 2023

@Lorak-mmk @avelanarius review ping

Copy link
Collaborator

@Lorak-mmk Lorak-mmk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one question: why is .into() in e.into_compile_error().into() required? Doesn't .into_compile_error() already return TokenStream?

@piodul
Copy link
Collaborator Author

piodul commented Oct 3, 2023

Just one question: why is .into() in e.into_compile_error().into() required? Doesn't .into_compile_error() already return TokenStream?

That's because into_compile_error() returns proc_macro2::TokenStream, whereas entry points to procedural macros must return proc_macro::TokenStream.

Ref: https://docs.rs/proc-macro2/latest/proc_macro2/

@piodul piodul merged commit d60a8d9 into scylladb:main Oct 5, 2023
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants