Open weiznich opened 1 month ago
proc-macros are in an unfortunate situation where the main crate depends on them but they generate code for the main crate, requiring them to know what is in the main crate. Another problem that crops up due to this cyclic relationship is that the proc-macro can generate code that is "too new" for the main crate if work isn't done by the end-user or the maintainer to keep them in lockstep (e.g. using =
version requirements).
Problem
Consider the following example:
Assuming that host and target match:
Given this situation: How do I resolve that while supporting both resolver versions. If the answer is: You cannot, then resolver = "2" is a breaking change and should have been marked as such (== shipping rust 2.0). I fully understand that it is far to late to roll back that change but I would like to see the cargo team to at least acknowledge that they broke something and that they should prioritizing working on a fix (and maybe more than working on implementing new features!).
Steps
For a real word example try to build the following crate:
This breaks diesel as we cannot encapsulate the proc-macros and the main crate as "one" unit.
Possible Solution(s)
resolver="1"
behavior.)Notes
See the offtopic part of https://github.com/rust-lang/cargo/issues/14406 for more discussion on this topic
Version