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
Some proc macros may want to ensure that they work properly for targets with only no_std supported, for example, as Rust 1.64 stabilizingcore::ffi::CStr, cstr can soon work in no_std, and it would be good if there is a way to test that.
One possible solution is to make it possible to specify target on a TestCases, for example,
Actually... if we are cross compiling, we may also need a way to have build-only tests (in addition to pass and compile_fail), since we can't run executable in a different target.
I would also like to see a feature like this for zerocopy-derive (a proc macro) so that even if I'm running my tests on a particular host (e.g., the Linux VMs supported by GitHub Actions), I can still make sure that zerocopy-derive produces correct code when the build target is a different architecture. This would entail trybuild invoking the compiler and instructing it to compile for a different target.
I think I would prefer not to build this into this crate, but it would be reasonable for someone else to maintain a more fully featured fork that handles this.
Some proc macros may want to ensure that they work properly for targets with only
no_std
supported, for example, as Rust 1.64 stabilizingcore::ffi::CStr
, cstr can soon work inno_std
, and it would be good if there is a way to test that.One possible solution is to make it possible to specify
target
on aTestCases
, for example,and then create a
.cargo/config.toml
in the generated test directory.What do you think?
Also if you are busy, I can work on this and raise a PR as long as you are fine with this feature.
The text was updated successfully, but these errors were encountered: