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

Fix ICE test in compiletest fail-tests #36335

Merged
merged 3 commits into from
Sep 23, 2016
Merged

Conversation

mcarton
Copy link
Member

@mcarton mcarton commented Sep 7, 2016

While working on Clippy which uses compiletest, I noticed that as long as all expected error are found, compile-fail tests will be marked ok even if there is an ICE. One function seems to have not been updated with JSON errors because ICEs are now reported like this:

{"message":"../src/librustc/ty/context.rs:161: Attempted to intern `_` which contains inference types/regions in the global type context","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":null}

I don't think I can add a test for that.

I guess:
r? @nikomatsakis

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@nikomatsakis
Copy link
Contributor

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Sep 13, 2016

📌 Commit dd6e386 has been approved by nikomatsakis

@nikomatsakis
Copy link
Contributor

@mcarton good catch =)

@bors
Copy link
Contributor

bors commented Sep 14, 2016

⌛ Testing commit dd6e386 with merge 5df533b...

@bors
Copy link
Contributor

bors commented Sep 14, 2016

💔 Test failed - auto-win-gnu-32-opt-rustbuild

@alexcrichton
Copy link
Member

@bors: retry

On Tue, Sep 13, 2016 at 8:30 PM, bors notifications@github.com wrote:

💔 Test failed - auto-win-gnu-32-opt-rustbuild
https://buildbot.rust-lang.org/builders/auto-win-gnu-32-opt-rustbuild/builds/2501


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#36335 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAD95Bx6QXitYEUbFtdUzNNAlFgtWAspks5qp2pHgaJpZM4J3dOj
.

@GuillaumeGomez
Copy link
Member

@GuillaumeGomez
Copy link
Member

@bors: rollup-

bors added a commit that referenced this pull request Sep 14, 2016
Rollup of 5 pull requests

- Successful merges: #36334, #36335, #36363, #36374, #36467
- Failed merges:
@mcarton
Copy link
Member Author

mcarton commented Sep 14, 2016

% rustc src/test/compile-fail/issue-31109.rs
error: internal compiler error: ../src/librustc_const_eval/eval.rs:1273: could not evaluate float literal (see issue #31407)
  --> src/test/compile-fail/issue-31109.rs:14:18
   |
14 |     let _: f64 = 1234567890123456789012345678901234567890e-340; //~ ERROR could not evaluate float
   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: the compiler unexpectedly panicked. this is a bug.

Looks weird to check for the presence of an ICE.
Should that be converted to a regular error?

@nikomatsakis
Copy link
Contributor

It sounds to me like the desired error is being reported and then,
separately, an ICE. In other words the PR is catching a latent bug.

On Sep 14, 2016 12:27 PM, "Martin Carton" notifications@github.com wrote:

% rustc src/test/compile-fail/issue-31109.rs
error: internal compiler error: ../src/librustc_const_eval/eval.rs:1273: could not evaluate float literal (see issue #31407)
--> src/test/compile-fail/issue-31109.rs:14:18
|
14 | let _: f64 = 1234567890123456789012345678901234567890e-340; //~ ERROR could not evaluate float
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: the compiler unexpectedly panicked. this is a bug.

Looks weird to check for the presence of an ICE.
Should that be converted to a regular error?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#36335 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAJeZverDK_qEjte5yhiQBt7ms8pVIE6ks5qqCCDgaJpZM4J3dOj
.

@bors
Copy link
Contributor

bors commented Sep 15, 2016

⌛ Testing commit dd6e386 with merge a0473dc...

@bors
Copy link
Contributor

bors commented Sep 15, 2016

💔 Test failed - auto-mac-32-opt

@mcarton
Copy link
Member Author

mcarton commented Sep 20, 2016

I've changed the error so that it does not ICE anymore.

@GuillaumeGomez
Copy link
Member

But it still fails travis. :p

@mcarton
Copy link
Member Author

mcarton commented Sep 22, 2016

This once, I've tested it 😅

@GuillaumeGomez
Copy link
Member

And travis seems happy. All good for me then. Thanks!

@bors: r+ rollup

@bors
Copy link
Contributor

bors commented Sep 23, 2016

📌 Commit bfa3433 has been approved by GuillaumeGomez

@bors
Copy link
Contributor

bors commented Sep 23, 2016

⌛ Testing commit bfa3433 with merge 86a686c...

bors added a commit that referenced this pull request Sep 23, 2016
Fix ICE test in compiletest fail-tests

While working on Clippy which uses *compiletest*, I noticed that as long as all expected error are found, *compile-fail* tests will be marked *ok* even if there is an ICE. One function seems to have not been updated with JSON errors because ICEs are now reported like this:
```json
{"message":"../src/librustc/ty/context.rs:161: Attempted to intern `_` which contains inference types/regions in the global type context","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":null}
```
I don't think I can add a test for that.

I guess:
r? @nikomatsakis
@hanna-kruppe
Copy link
Contributor

I only now saw this PR. When I introduced that test in #31410 I was told to make it a span_bug rather than an ordinary error. So it's not a latent bug, it was an "intentional ICE". Maybe whoever has the last word on that decides that ICE-ing on known issues isn't good, but I do want to bring it up just to be sure.

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

Successfully merging this pull request may close these issues.

7 participants