You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#[faux::methods]creates a module with the name of the struct being mocked.
This means that if there are multiple impl blocks for the same type, two modules with the same name would be created in the same scope, hence collide, and fail to compile.
rust-lang/rust#8995 would lift the requirement of making the dummy modules and fix this but I do not see an ETA in it being done soon.
Multiple impls within the same module is rare since we do not support generics nor trait impls but once we start supporting them this issue would become more important.
Multiple impls are allowed as long as there is no more than one inherent implementation and no more than one trait implementation per trait.
The user can get around this by wrapping impls in a separate module themselves, but forcing the user to write hacks to support this library would be very subpar UX.
A possible solution would be to mock an entire module but that is a bit far from being implemented,
The text was updated successfully, but these errors were encountered:
As part of solving #10 a decision was made to also include trait names in the name of the load bearing mod that causes the problem in this issue. This means that an user CAN have multiple impl blocks in a mod as long as no more than one is an inherent implementation impl MyStruct {}, and the rest are all for different traits: impl TraitA for MyStruct {}impl TraitB for MyStruct {} works.
#[faux::methods]
creates a module with the name of the struct being mocked.This means that if there are multiple
impl
blocks for the same type, two modules with the same name would be created in the same scope, hence collide, and fail to compile.rust-lang/rust#8995 would lift the requirement of making the dummy modules and fix this but I do not see an ETA in it being done soon.
Multiple impls within the same module is rare
since we do not support generics nor trait impls but once we start supporting them this issue would become more important.Multiple impls are allowed as long as there is no more than one inherent implementation and no more than one trait implementation per trait.
The user can get around this by wrapping impls in a separate module themselves, but forcing the user to write hacks to support this library would be very subpar UX.
A possible solution would be to mock an entire module but that is a bit far from being implemented,
The text was updated successfully, but these errors were encountered: