Crates.io | qualify-derive |
lib.rs | qualify-derive |
version | 0.1.2 |
source | src |
created_at | 2020-09-22 11:19:44.180675 |
updated_at | 2020-09-22 15:02:31.315809 |
description | Simple utility for wrapping derive macros that do not qualify paths properly |
homepage | |
repository | https://github.com/SOF3/qualify-derive |
max_upload_size | |
id | 291511 |
size | 19,260 |
Simple utility for wrapping derive macros that do not qualify paths properly.
For example, specs v0.16.1 has a derive macro Component
.
If the #[storage]
is not passed with the macro,
it generates a line type Storage = DenseVecStorage;
,
which causes compile errors when DenseVecStorage
is not already imported.
It is annoying to manually add an import for a derive macro all the time.
qualify-derive
assists with creating a wrapper macro that automatically imports them.
Create a new crate with this Cargo.toml (proc macros won't work in the current crate):
[package]
name = # the usual [package] stuff
[lib]
proc-macro = true
[dependencies]
qualify-derive = "0.1.1"
Then create src/lib.rs
with the following cntents:
qualify_derive::declare! {
your_attribute_name derives ::full_path_to::TargetDeriveMacro;
use the_paths::you_want_to::import_automatically;
use import_groups_are::not_supported;
// use foo::{bar, qux}; // this does not work
attr this_line_is_optional
}
This declares a proc-macro-attribute called your_attribute_name
.
In downstream crates, you can use #[your_attribute_name]
in place of #[derive(::full_path_to::TargetDeriveMacro)]
.
attr this_line_is_optional
will allow downstream crates to use #[your_attribute_name(some content here)]
,
which is expanded into #[derive(::full_path_to::TargetDeriveMacro)] #[this_line_is_optional(some content here)]
.
See test-macro
and test-lib
.
cargo fix
when they are unused.
cargo fix
removes the attribute if the type is unused.super
would refer to the module that the type itself is declared in.
However, all symbols in the super
scope are automatically imported down to the scope of the inner module,
so it is not necessary to use super::
inside the type;
but any use of super
would be incorrect.
Use super::super
or absolute paths from crate::
instead.