generator: better macro hygiene #192
Conversation
This change introduces the alias `rinja` that is used for every integration crate. This way we need less string concatenization at runtime.
This way, even a shadowed `core` or `std` does not prevent the generated code from working correctly.
rinja/src/lib.rs
Outdated
| @@ -67,6 +67,8 @@ mod html; | |||
| use std::{fmt, io}; | |||
|
|
|||
| pub use rinja_derive::Template; | |||
| #[doc(hidden)] | |||
| pub use {core, std}; | |||
There was a problem hiding this comment.
You can refer to core and std by prepending them with :: in macros. Like ::core::whatever. If not, then add a comment to explain why we want it. Also, it's really not great because it's not rare for users to do use rinja::*;.
There was a problem hiding this comment.
The current code already does that, but even fully-qualified paths like ::core and ::std can be shadowed. See the example in testing.
But yeah, I didn't recognize the problem that use rinja::* would import the symbol core, too, which might be undesirable. Python is smarter than rust in a way: Symbols with a leading underscore are omitted from glob imports. Would be nice if rust did that, too.
I guess I'll simply move the re-exports into the existing #[doc(hidden)] mod helpers. The name already exists, so it can't introduce a new problem.
There was a problem hiding this comment.
A new module containing it would be better indeed. 👍
|
Great work, thanks! |
|
Thank you! And, as usual, thank you for reviewing! :) |
rinja, so we need less string concatenation at runtime#![no_implicit_prelude]context, even ifstdand/orcoreare shadowedThis PR is done in anticipation of #191, but IMHO it is also a good change on its own.
Once the new feature is added (which probably will take quite some time), we can replace
extern crate #CRATE as rinjawithuse #macro_input as rinjawherebymacro_inputis the identifier$crateof the macro.