-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
hide prelude imports inside a local module to allow shadowing imports #222
Conversation
allows more control than `--hide-prelude` which disables everything, but is also likely to break for people who only override one struct, because we might add more structs to our prelude. fixes #214 Signed-off-by: clux <sszynrae@gmail.com>
Signed-off-by: clux <sszynrae@gmail.com>
cc @Dav1dde who maybe has opinions |
Not quite up to date, the main problem why I think instead of trying to be smart with imports another solution could be to just keep filling the prelude but hide all unused warnings etc. #![allow(unused)]
mod prelude {
pub use std::collections::HashMap as Map;
}
use self::prelude::*;
// User supplied
use std::collections::BTreeMap as Map; The generated code doesn't need to be perfect (it's machine generated after all), I've ran into similar issues in glad, where it's just better to take the solution which is readable enough but allows for way more flexibility in generation. |
yeah!
for some reason i didn't understand this the first time i looked at it, but now i think it makes sense. kopium X > crd.rs
echo "use mycrate::Map as Map;" >> crd.rs then your setup there seems a lot easier to maintain, i'll try it out! sorry for the delay. |
Signed-off-by: clux <sszynrae@gmail.com>
--no-import
flag for granular import controlSigned-off-by: clux <sszynrae@gmail.com>
Signed-off-by: clux <sszynrae@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I was thinking of! Should allow us to add multiple unconditional imports in the future while at the same time not breaking user overrides.
allows more control than
--hide-prelude
which disables everything, but is also likely to break for people who only override one struct, because we might add more structs to our prelude (as happened when we addedCondition
to our imports).following David's Idea below, the generated output now wraps imports in a private module:
so that to override any of these users can add extra overrides to any part of it using shadowing:
fixes #214