-
-
Notifications
You must be signed in to change notification settings - Fork 221
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
Keep the template source code portion corresponding to each AST token #926
Comments
Do you have an example error message that sucked for you? In general I think this makes sense, just hoping it doesn't add too much complexity in the parser. |
The last case I had was:
So I had to go around to check where this macro was called exactly. Would have been nice to have:
As for the overhead, not sure how big it might be. However it'll greatly improve error messages for sure. :) |
Makes sense, looking forward to review! @vallentin @Kijewski how do you feel about asking @GuillaumeGomez to join us as a co-maintainer? @GuillaumeGomez would you be interested? |
Fine with me. My contributions have been sporadic lately, due to being busy. So another set of talented hands, is definitely welcome! |
If I can help with reviews, then sure. Thanks for the offer! :) |
@Kijewski friendly ping? |
Sorry, I'm kinda overwhelmed by work right now and did not see the message. Of course, fine with me. Welcome, @GuillaumeGomez! :) |
❤️ |
No problem, hope you can enjoy a nice holiday toward the end of the year! |
In a lot of cases, we emit errors when generating the Rust code in the proc-macro, however we only emit an error without showing where it comes from in the template.
To improve this situation, we could keep a
Option<&str>
or at least aOption<Range>
(which would point to the template source, however this second solution brings its own issues, like when the error comes from imports/extends).What do you think?
The text was updated successfully, but these errors were encountered: