Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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.

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

No branches or pull requests

1 participant