Skip to content

Better error handling #544

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

Merged
merged 1 commit into from
Nov 2, 2021

Conversation

robamu
Copy link
Contributor

@robamu robamu commented Oct 31, 2021

Just a small attempt to make svd2rust print more useful information if something goes wrong in the TokenStream generation, or in general

  • More debug output in case something goes wrong in the TokenStream generation
  • Some info output in the main

I like how the svd XML parser handles errors by passing an Error Enum with a node ID up which can be used by one central error handler to print diagnostic information. I don't think it can be done like that here, so I simply print out some locally available information (peripheral name, register name etc.) as the error is propagated

@robamu robamu requested a review from a team as a code owner October 31, 2021 12:09
@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @burrbull (or someone else) soon.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-tools labels Oct 31, 2021
Copy link
Member

@Emilgardis Emilgardis left a comment

Choose a reason for hiding this comment

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

nicely done! Some suggestions.

Tracing would be nice to have, but not necessary to implement right now

@burrbull
Copy link
Member

Instead of log::error! it is enough to use anyhow::with_context here

@Emilgardis
Copy link
Member

Instead of log::error! it is enough to use anyhow::with_context here

Indeed, however some of these functions return syn::Error, so those would have to be changed as well, but that would bring some better usability like with_context 👍

@robamu
Copy link
Contributor Author

robamu commented Oct 31, 2021

I integrated most suggestions. Sample output on failure:

[INFO  svd2rust] Parsing device from SVD file
[INFO  svd2rust] Rendering devices
[ERROR svd2rust] Error rendering devices
    
    Caused by:
        0: Rendering error at peripheral IRQSEL
           Description: Interrupt Selector Peripheral
           Group: No group name
        1: Issue expanding register or cluster block
        2: Error expanding register
           Name: PORTA[%s]
           Description: PORTA Interrupt Redirect Selection
        3: syn error occured
        4: Error converting info name PORTA[%s]
        5: Determining syn::TypePath from ident "crate::Reg<porta%s::PORTA%S_SPEC>" failed
        6: expected `,`

@burrbull
Copy link
Member

Looks good!

@robamu
Copy link
Contributor Author

robamu commented Oct 31, 2021

I'm tweaking the output a bit:

[INFO  svd2rust] Parsing device from SVD file
[INFO  svd2rust] Rendering devices
[ERROR svd2rust] Error rendering devices
    
    Caused by:
        0: Rendering error at peripheral
           Name: IRQSEL
           Description: Interrupt Selector Peripheral
           Group: No group name
        1: Issue expanding register or cluster block
        2: Error expanding register
           Name: PORTA[%s]
           Description: PORTA Interrupt Redirect Selection
        3: syn error occured
        4: Error converting info name PORTA[%s]
        5: Determining syn::TypePath from ident "crate::Reg<porta%s::PORTA%S_SPEC>" failed
        6: expected `,`

@robamu
Copy link
Contributor Author

robamu commented Oct 31, 2021

I think its always just one device which is parsed so I might tweak that output too

@burrbull
Copy link
Member

Squash commits, please.

@robamu robamu force-pushed the mueller/more-diagnostic-output branch from 6581177 to 122b262 Compare October 31, 2021 16:37
@robamu
Copy link
Contributor Author

robamu commented Oct 31, 2021

I'll run rustfmt and clippy and then squash again

@robamu robamu force-pushed the mueller/more-diagnostic-output branch from 8b3170f to e92ea34 Compare October 31, 2021 18:29
Copy link
Member

@Emilgardis Emilgardis left a comment

Choose a reason for hiding this comment

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

Lgtm! Thank you!

bors r+

bors bot added a commit that referenced this pull request Nov 1, 2021
544: Better error handling r=Emilgardis a=robamu

Just a small attempt to make `svd2rust` print more useful information if something goes wrong in the TokenStream generation, or in general

- More debug output in case something goes wrong in the TokenStream generation
- Some info output in the main

I like how the `svd` XML parser handles errors by passing an Error Enum with a node ID up which can be used by one central error handler to print diagnostic information. I don't think it can be done like that here, so I simply print out some locally available information (peripheral name, register name etc.) as the error is propagated

Co-authored-by: Robin Mueller <robin.mueller.m@gmail.com>
@Emilgardis
Copy link
Member

bors r-

Sorry, minor nit

@bors
Copy link
Contributor

bors bot commented Nov 1, 2021

Canceled.

- More diagnostic output in case something goes wrong in the TokenStream
generation, using `with_context` functions of `anyhow::Result`
- Some info output in the main
@robamu robamu force-pushed the mueller/more-diagnostic-output branch from 90e9f9b to d534093 Compare November 2, 2021 08:20
@burrbull
Copy link
Member

burrbull commented Nov 2, 2021

bors r+

@bors
Copy link
Contributor

bors bot commented Nov 2, 2021

Build succeeded:

@bors bors bot merged commit f4b0e64 into rust-embedded:master Nov 2, 2021
@robamu robamu deleted the mueller/more-diagnostic-output branch November 2, 2021 09:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants