Closed Fraser999 closed 9 years ago
Thanks for the pull request!
Unfortunately, these changes do not cover all cases, and I worry that fixing it in only some cases might be confusing. In particular, if a schema has constants defined at the outermost level, they will still emit dead code warnings. The natural solution is to put the #![allow(...)]
directives at the very top of the generated code, but then the generated code would not be importable with the include!()
macro (cf. https://github.com/rust-lang/rfcs/issues/752). That, in turn, would not be a problem if we could use the mod_path syntax extension, but it doesn't work on the stable release channel. So for now the recommended solution is to manually suppress the warnings.
Hmm. I suppose a somewhat nicer workaround might be to define an mod_capnp!()
macro that automatically includes generated code under OUT_DIR
and adds the allow directives.
What do you think?
The proposed mod_capnp!()
would expand
mod_capnp!(addressbook_capnp, "/addressbook_capnp.rs");
into
#[allow(dead_code, missing_docs)]
mod addressbook_capnp {
include!(concat!(env!("OUT_DIR"), "/addressbook_capnp.rs"));
}
There could be a similar pub_mod_capnp!()
.
Yeah - that looks like a better solution indeed - I hadn't considered outer scope constants.
I'm still new to Rust and Cap'n Proto, so forgive the question, but could we get away with only passing the path into the macro since the module name will always be the same as the filename (minus the extension) won't it?
Regardless, I'll close this pull request and await the macro fix :)
This just adds
dead_code
andmissing_docs
to the existing allowed lint checks. This will be a problem for any project trying to useforbid
for these, but I don't see a good way round that.