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

Add tests for #58319 and #65131 #70176

Merged
merged 1 commit into from
Mar 21, 2020
Merged

Add tests for #58319 and #65131 #70176

merged 1 commit into from
Mar 21, 2020

Conversation

rylev
Copy link
Member

@rylev rylev commented Mar 20, 2020

Fixes #58319 and fixes #65131

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 20, 2020
@rylev
Copy link
Member Author

rylev commented Mar 20, 2020

r? @Centril

@Centril
Copy link
Contributor

Centril commented Mar 20, 2020

Thanks! @bors r+

@bors
Copy link
Contributor

bors commented Mar 20, 2020

📌 Commit 5444ade has been approved by Centril

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 20, 2020
Centril added a commit to Centril/rust that referenced this pull request Mar 21, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 21, 2020
Rollup of 16 pull requests

Successful merges:

 - rust-lang#65097 (Make std::sync::Arc compatible with ThreadSanitizer)
 - rust-lang#69033 (Use generator resume arguments in the async/await lowering)
 - rust-lang#69997 (add `Option::{zip,zip_with}` methods under "option_zip" gate)
 - rust-lang#70038 (Remove the call that makes miri fail)
 - rust-lang#70058 (can_begin_literal_maybe_minus: `true` on `"-"? lit` NTs.)
 - rust-lang#70111 (BTreeMap: remove shared root)
 - rust-lang#70139 (add delay_span_bug to TransmuteSizeDiff, just to be sure)
 - rust-lang#70165 (Remove the erase regions MIR transform)
 - rust-lang#70166 (Derive PartialEq, Eq and Hash for RangeInclusive)
 - rust-lang#70176 (Add tests for rust-lang#58319 and rust-lang#65131)
 - rust-lang#70177 (Fix oudated comment for NamedRegionMap)
 - rust-lang#70184 (expand_include: set `.directory` to dir of included file.)
 - rust-lang#70187 (more clippy fixes)
 - rust-lang#70188 (Clean up E0439 explanation)
 - rust-lang#70189 (Abi::is_signed: assert that we are a Scalar)
 - rust-lang#70194 (#[must_use] on split_off())

Failed merges:

r? @ghost
@bors bors merged commit 855eac3 into rust-lang:master Mar 21, 2020
@tanriol
Copy link
Contributor

tanriol commented Mar 21, 2020

@rylev, could you please clarify how this helps #65131? It is not an ICE - the compilation produces the same error in both cases. The pre-fix version was much slower (25 seconds versus less than one), but I don't see any special timeout handling here.

@rylev
Copy link
Member Author

rylev commented Mar 23, 2020

@tanriol This is a good point. The expectation is that a hanging test would otherwise be noticed, but I can see how that's an unrealistic expectation. I'm not sure if there is support for ensuring tests don't run too long. Is there something like this @Centril?

@rylev rylev deleted the ice-tests branch March 23, 2020 09:18
@Centril
Copy link
Contributor

Centril commented Mar 23, 2020

Oh; it was just 25s vs. 1s? Well that wouldn't make any difference in the testsuite in CI terms, but I guess folks might notice locally. cc @Mark-Simulacrum in case they know how to ensure a test doesn't run too long; if not, perhaps we should add support to compiletest?

@Mark-Simulacrum
Copy link
Member

If we want to compare performance, the test should go onto perf.rlo, not into UI tests; UI tests are not intended for performance comparisons today.

If we just want to make sure the test doesn't take too long (and 25 seconds is pretty long -- are we sure we need such a long test? Though it sounds like maybe it's shorter now), then I just wouldn't worry about it, if it finishes relatively quickly locally then that's good enough. I would recommend trying to make sure tests finish in less than 1 second.

@tanriol
Copy link
Contributor

tanriol commented Mar 23, 2020

@Mark-Simulacrum This is intended to be a regression test for a specific performance fix that reduced the asymptotic compile time on the test snippet from O(N^3) to something like O(N) (where N is the number of macro-generated if statements).

While in general perf.rlo is the correct place for benchmarks, I'm not sure whether this test is representative enough to make much sense there (as in "is it worth being a plot on the perf.rlo front page"). The idea is just to have a test that the asymptotic performance does not accidentally become much worse. The situation under test is a corner case (reporting borrow errors in huge functions) that normally does not come up unless you're debugging code generation (and your generator makes huge functions), so such a regression could go unnoticed.

@Mark-Simulacrum
Copy link
Member

Mark-Simulacrum commented Mar 23, 2020

If it's short (or can be made to compile quickly, roughly in less than 2 seconds, after the fix) we can add it to perf, I wouldn't worry too much about "representative" in that sense. That certainly sounds like a test that should be on perf and wouldn't make much sense as a test in this repository.

@rylev
Copy link
Member Author

rylev commented Mar 23, 2020

@Mark-Simulacrum the test compiles very quickly now. I can move it to perf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
7 participants