-
Couldn't load subscription status.
- Fork 13.9k
compiletest: Don't set TARGET for non run-make tests
#147929
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
Conversation
There are a few tests that were trying to skip i586 targets via the `TARGET` environment variable instead, so better to just add support for the directive.
If something like this is needed again in the future, please set environment variables for the build and run subprocesses, instead of setting them on the compiletest process.
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
compiletest: Don't set `TARGET` for non run-make tests try-job: dist-i586-gnu-i586-i686-musl try-job: i686-gnu-1 try-job: i686-msvc-1 try-job: test-various
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
@bors r+ rollup |
Rollup merge of #147929 - Zalathar:target, r=jieyouxu compiletest: Don't set `TARGET` for non run-make tests There are a few tests that were using `TARGET` to quietly do nothing on `i586` targets, but it's cleaner to just add support for `//@ ignore-i586` instead. This lets us get rid of an unsafe `env::set_var` in compiletest, which really should have been setting the environment variable on individual build/run subprocess commands anyway. - The original code and tests were introduced way back in #39068
There are a few tests that were using
TARGETto quietly do nothing oni586targets, but it's cleaner to just add support for//@ ignore-i586instead.This lets us get rid of an unsafe
env::set_varin compiletest, which really should have been setting the environment variable on individual build/run subprocess commands anyway.