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

Various tests break if optimize-tests = false in config.toml #55757

Closed
pnkfelix opened this issue Nov 7, 2018 · 3 comments
Closed

Various tests break if optimize-tests = false in config.toml #55757

pnkfelix opened this issue Nov 7, 2018 · 3 comments

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Nov 7, 2018

Some number of tests in the test suite will break if you turn off optimization. (The breakage is usually not terrible; e.g. sometimes its mild difference in diagnostic output.)

This is nonetheless a real problem because there is no good way to work around it. For example, there is no way for a test to specify that it requires a certain opt-level.

pnkfelix added a commit to pnkfelix/rust that referenced this issue Nov 7, 2018
…rom `rustc -O`.

(The fact that output differs under `opt-level=0` is an instance of rust-lang#55757.)
@pnkfelix
Copy link
Member Author

pnkfelix commented Nov 7, 2018

Hmm, @oli-obk points out (#55532 (comment)) that one can add // compile-flags: -O to such tests to sidestep the behavior.

And that's true: One can pass -O multiple times to the compiler.

I had thought you couldn't, because what you cannot do is pass -O -C opt-level=0. I.e., there's a still a problem in that tests cannot specify that they require optimizations to be turned off.

@pnkfelix
Copy link
Member Author

The main symptom of this problem on OS X will be resolved if #54153 is closed by PR #56772

I'll go look if Linux has any similar issues.

If it doesn't... then I may close this. I'm tempted to still leave it open because tests should have some way to override the setting in config.toml. But that might be better left for a broader compiletest overhaul.

@pnkfelix
Copy link
Member Author

Linux didn't have any analogous issues here. And I think PR #56772 will (eventually) go through. So I'm closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant