It would be nice if my regression can be added somewhere to be tested under no_std during CI jobs.

I can add some code for this -- please let me know how you want this to be.

I don't think we need to change it in all creates but just in rstest. The procedural macros ones and the others can still use std.

Maybe a little deep look to the rendering module can be useful, but just where it render some code that directly reference std

hey, I know where exactly I have to make changes only for my issue.

but, don't you think that it would make sense to use core over std wherever it is possible ?

What I mean is that just the library crate should be nostd bceause it's used by the expanded code. The code in rstest_macro crate is executed by the compiler and so can always use std library.

Now in rstest_macros::render code maybe there is some quoted code that use std path... we should just check it

Some examples in rstest_macros

• https://github.com/la10736/rstest/blob/master/rstest_macros/src/render/apply_arguments.rs#L121
• https://github.com/la10736/rstest/blob/master/rstest_macros/src/render/fixture.rs#L25-L30
• https://github.com/la10736/rstest/blob/master/rstest_macros/src/render/inject.rs#L113
• https://github.com/la10736/rstest/blob/master/rstest_macros/src/render/mod.rs#L211

Moreover a nice to have... end to end test that expose the issue and then is fixed by your code

I reverted the core usage from the old commit. I now use core only in rstest_macros/src/render and rstest/src/magic_conversion.

I can't make rstest/src/timeout no_std compatible -- as it requires mpsc and thread from std.

Sorry, I've answered before without put enough brain in it .... sorry.

As I already commented in the linked ticket the library rstest can still remain in std because it will be linked in an std compatible executable. Only the rendered code should use references from core instead std just because they can be compiled in a library that doesn't have the std crate in its namespace.

Anyway in a future I'll remove all references to common code and just reexport them in rstest ... this should be the best way

the library rstest can still remain in std because it will be linked in an std compatible executable.

Gotcha! I reverted the changes in rstest crate. the changes are only in rstest_macros crate at the generate codes.

Ok, I merge it. But I'll add at least a e2e test before publish it

Hey, many thanks for merging this. Sorry, I couldn't get some time to add the changelog entry and the e2e test.