#Mocking derive macro for proc macro tests

11 messages · Page 1 of 1 (latest)

minor mesa
#

This might be an XY problem, so here is what I'm doing:
I'm making a proc-macro to help derive a bunch of boilerplate for one of our game parts, specifically our input handling. This will convert from leafwing-input-manager's input format to our own that has a bunch of convenience methods.

The issue is that inside this expansion, there are two derive macros: leafwing_input_manager::Actionlike (not too bad to manually implement) and bevy_reflect::Reflect (very bad). I don't want to include these as a dependency on the proc macro crate since they are so big, and I don't even care about their expansion, I just want to see that my proc macro expands correctly.

Thus the question: How should I do this, so that I can see the expansion of my proc macro, without getting the "cannot find derive maco" errors? I also don't want to have to include them in my proc macro crate, since as far as I can tell there is no way to make them test only, so then confusion would just be added.

vivid hazel
minor mesa
#

Which I have done before by including it in the proc macro crate, but that lead to having two derives for the same thing which is very confusing.
In the tests all the mocks did is this: ```rust
#[derive(Actionlike, Reflect)]
enum A{}

Expands to ```rust
#[derive(Actionlike, Reflect)]
enum A{}
impl Actionlike for A {}
impl Reflect for A{}
vivid hazel
#

I'm still not understanding the actual problem

minor mesa
#

It's basically I want three things, but all the solutions I see can only let me have two:

  1. Keep compile times low by not including leafwing-input-manager and bevy-reflect as dependencies
  2. Have a test that expands to my macro's code without derive macro missing errors
  3. Not have dummy derive macros for Actionlike and Reflect in my proc macro crate
#

2 & 3 are possible, but that ruins compile times.
1 & 2 are possible, but that makes for a confusing time using my crate in addition to the other two.
1 & 3 are possible, but that stops compilation early so I don't get actually useful errors from my test.

vivid hazel
#

What does 2 look like

#

How can you test a macro expansion without even trying if it compiles

minor mesa
#

It doesn't compile fully, but RA can still expand my proc macro.

#

And since I'm still making it, I wouldn't have a good automated test case anyways, so it's almost enough, but seeing other errors/warns to silence i really helpful.