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