Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support specifying target for test cases #184

Closed
upsuper opened this issue Aug 6, 2022 · 3 comments
Closed

Support specifying target for test cases #184

upsuper opened this issue Aug 6, 2022 · 3 comments
Labels
out of scope Ideas to consider for someone building a more fully featured ui testing library

Comments

@upsuper
Copy link

upsuper commented Aug 6, 2022

Some proc macros may want to ensure that they work properly for targets with only no_std supported, for example, as Rust 1.64 stabilizing core::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,

impl TestCases {
    pub fn with_target(target: &'static str) -> Self;
}

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.

@upsuper
Copy link
Author

upsuper commented Aug 6, 2022

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.

@joshlf
Copy link

joshlf commented Oct 5, 2022

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.

@dtolnay
Copy link
Owner

dtolnay commented Oct 26, 2022

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.

@dtolnay dtolnay closed this as completed Oct 26, 2022
@dtolnay dtolnay added the out of scope Ideas to consider for someone building a more fully featured ui testing library label Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
out of scope Ideas to consider for someone building a more fully featured ui testing library
Projects
None yet
Development

No branches or pull requests

3 participants