Split crate into a proc-macro and a regular library crate #214
Conversation
proc-macro crates are loaded by the compiler instead of by the crate that depends on it. This means it's not possible to use anything else than exported anything else than exported proc-macros. But in some cases we want the generated derives to use structs or traits that are provided by the library. Two examples of this are: 1. An error type that can be used by the `Into` derive ([#173][173]) 2. Or to support trait objects for the `source` of the `Error` derive ([#122][122]) This change splits the layout of this crate in two. One crate that only exports proc-macros and is loaded by the compiler. And a second crate that re-exports all these macros but is also able to export different things such as structs and traits. NOTE: This only refactors the code in this repo. No functional changes happen in this change. These will be done in follow-up PRs. [173]: #173 [122]: #122
JelteF
force-pushed
the
change-into-error
branch
from
326771e
to
6f52e18
Compare
There was a problem hiding this comment.
@JelteF I've provided my changes to the feedback as separate commits, so you may revert them granularly if you do mind about some change.
I've tried to leave you as little work as possible, considering the moments where I'm unsure how to act.
| @@ -29,236 +29,5 @@ | |||
| #![cfg_attr(docsrs, feature(doc_auto_cfg))] | |||
| #![recursion_limit = "128"] | |||
| #![deny(rustdoc::broken_intra_doc_links, rustdoc::private_intra_doc_links)] | |||
| #![forbid(non_ascii_idents, unsafe_code)] | |||
There was a problem hiding this comment.
I don't see the reason for these lints not being turned on in both crates simultaneously.
| @@ -29,236 +29,5 @@ | |||
| #![cfg_attr(docsrs, feature(doc_auto_cfg))] | |||
| #![recursion_limit = "128"] | |||
| #![deny(rustdoc::broken_intra_doc_links, rustdoc::private_intra_doc_links)] | |||
| ); | ||
|
|
||
| create_derive!("unwrap", unwrap, Unwrap, unwrap_derive, unwrap); | ||
| pub use derive_more_impl::*; |
There was a problem hiding this comment.
#[doc(inline)] seems to be useful here.
src/lib.rs
Outdated
| @@ -29,236 +29,5 @@ | |||
| #![cfg_attr(docsrs, feature(doc_auto_cfg))] | |||
| #![recursion_limit = "128"] | |||
There was a problem hiding this comment.
This attribute seems to belong to proc-macro crate, as required by the implementation. We don't need it for re-export.
| authors = ["Jelte Fennema <github-tech@jeltef.nl>"] | ||
| license = "MIT" | ||
| repository = "https://github.com/JelteF/derive_more" | ||
| documentation = "https://docs.rs/derive_more" |
There was a problem hiding this comment.
Is this intentionally not https://docs.rs/derive_more-impl?
impl/Cargo.toml
Outdated
|
|
||
| [dev-dependencies] | ||
| rustversion = "1.0" | ||
| trybuild = "1.0.56" |
There was a problem hiding this comment.
Seems that we don't need this in the -impl crate, as the test lay in the main crate.
There was a problem hiding this comment.
Meh... we still do need rustc_version due to #[cfg(nightly)] in error.md examples.
There was a problem hiding this comment.
Corrected tests and their features in fd90267.
|
ping @JelteF |
1 similar comment
|
ping @JelteF |
proc-macro crates are loaded by the compiler instead of by the crate
that depends on it. This means it's not possible to use anything else
than exported anything else than exported proc-macros. But in some cases
we want the generated derives to use structs or traits that are provided
by the library. Two examples of this are:
Intoderive (#173)sourceof theErrorderive (#122)This change splits the layout of this crate in two. One crate that only
exports proc-macros and is loaded by the compiler. And a second crate
that re-exports all these macros but is also able to export different
things such as structs and traits.
NOTE: This only refactors the code in this repo. No functional changes
happen in this change. These will be done in follow-up PRs.
Required for #173 #122