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
I've a scenario where I've a tests-utils crate that contain some stuff useful for testing.
This crate notably re-export rstest so I just have to import the utility crate when needed.
But with crate-name feature disable, the test fail to compile with the following error:
error[E0433]: failed to resolve:use of undeclared crate or module `rstest`
--> src/lib.rs:3:5
|
3 | #[test_utils::utils::rstest::rstest]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use of undeclared crate or module `rstest`
|
= note: this error originates in the attribute macro `test_utils::utils::rstest::rstest` (in Nightlybuilds, run with -Z macro-backtrace for more info)
error[E0425]: cannot find function, tuple struct or tuple variant `Magic` in this scope
--> src/lib.rs:3:5
|
3 | #[test_utils::utils::rstest::rstest]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
|
= note: this error originates in the attribute macro `test_utils::utils::rstest::rstest` (in Nightly builds, run with -Z macro-backtrace for more info)
Using cargo expand, I can see that the issue is caused by the use rstest::magic_conversion::*.
AFAIK there is no way to know how the user call a procedural macro in a procedural macro: to be more explicit rstest procedural macro will not receive test_utils::utils::rstest::rstest path anymore: that means that isn't possible to know how to identify the crate path where rstest is. Unfortunately in procedural macro you don't have the $crate like in normal macro's to identify the crate where the macro come, the crate-name feature just use a work around but suppose that rstest is imported as dependency in you manifest.
But, even if I was able to identify the path, your crate should also rexport all rstest pub's.
Only way to do it is feature gate the lib utilities like magic conversion and timeout. But I'm not sure it's a worth of it.
If you would provide a PR for feature gating these functionalities, enabled by default with a clear error in the case that a use a function gated out, I'll be happy to review and include it.
AFAIK there is no way to know how the user call a procedural macro in a procedural macro:
to be more explicit rstest procedural macro will not receive test_utils::utils::rstest::rstest
I understand that, that's why I proposed to add the attribute crate to allow user to indicate the path to rstest crate.
Hello,
I've a scenario where I've a
tests-utils
crate that contain some stuff useful for testing.This crate notably re-export
rstest
so I just have to import the utility crate when needed.So it can be used like this:
But with
crate-name
feature disable, the test fail to compile with the following error:Using
cargo expand
, I can see that the issue is caused by theuse rstest::magic_conversion::*
.If I enable
crate-name
feature, I get another error:I would like to known if you are interested to add the attribute
crate
tofixture
andrstest
macro to allow to specify the path to therstest
crate?It would be used like this:
This issue is similar to #221 but here the crate
rstest
is not renamed but re-exported from another crate.I could provide a PR if needed.
Sources code
cargo.toml
:src/lib.rs
:test-utils/Cargo.toml
:test-utils/src/lib.rs
:The text was updated successfully, but these errors were encountered: