I have a proc-macro crate with a macro that, when expanded, needs to use custom trait implementations for Rust built-in types. I tried to define the trait in the same crate, but
The way this is usually dealt with is to not have users depend on your proc-macro crate at all.
Your problem can be solved with 3 crates:
Whenever your macro mentions the shared types in its generated code, you need to use the fully-qualified names so that users don't also need to import them.
Some popular examples of this pattern in the wild:
thiserror-impl
which contains the actual macrospin-project-internal
which again contains the macrosdarling-core
and darling-macro
, which itself also depends on darling-core