Return nonzero exit code if there are errors at a stop point by fhahn · Pull Request #22117 · rust-lang/rust

fhahn · 2015-02-09T19:10:16Z

At the moment, when compilation is stopped at a stop point (like -Z parse-only), rustc does not return an nonzero exit code even if there are errors (expect fatal ones, that cause it to panic immediately). As an example, compiling src/test/compile-fail/doc-before-semi.rs with -Z parse-only raises an error, but exists with 0.

Note that I could not use sess.abort_if_errors() in the macro, because sess is passed by value and move at some point.

rust-highfive · 2015-02-09T19:10:28Z

r? @nikomatsakis

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

nikomatsakis · 2015-02-09T19:29:47Z

Can you add some kind of test for this?

brson · 2015-02-13T22:42:29Z

@nikomatsakis #22118 contains a bunch of test cases for this. Since those are the intended use it may be hard to dig up other relevant test cases.

fhahn · 2015-02-13T23:08:54Z

@nikomatsakis @brson yes, I would like to add the -Z parse-only flag to all parse-fail tests after #22118 lands to test this patch. Also I am going to check if there are test cases that fail at other stop points with this patch.

fhahn · 2015-02-17T22:30:49Z

@brson I have updated the patch to use a straight forward solution to invoke the diagnostics handler. I added a session argument to the controller_entry_point macro to pass the current valid session. This way we can handle the case were sessiongot moved.

After making `rustc` fail on errors at a stop point, like `-Z parse-only`, in rust-lang#22117, the files in this PR also fail during the parse stage and should be moved as well. Sorry for spliting this move up in two PRs.

fhahn · 2015-02-22T23:42:13Z

@brson what do you think about the new approach? Is it more reasonable?

pczarn · 2015-03-07T16:55:28Z

Needs rebase

fhahn · 2015-03-07T19:58:32Z

Thanks, I have rebased the PR.

bors · 2015-03-17T00:53:13Z

☔ The latest upstream changes (presumably #23331) made this pull request unmergeable. Please resolve the merge conflicts.

fhahn · 2015-03-20T19:11:56Z

I have resolved the merge conflicts.

bors · 2015-03-24T21:04:02Z

☔ The latest upstream changes (presumably #23654) made this pull request unmergeable. Please resolve the merge conflicts.

fhahn · 2015-03-26T15:48:38Z

rebased this PR again

bors · 2015-04-03T18:32:54Z

☔ The latest upstream changes (presumably #23930) made this pull request unmergeable. Please resolve the merge conflicts.

tamird · 2015-04-05T04:40:04Z

can this be globally added to parse-fail rather than in each test file?

nikomatsakis · 2015-04-18T09:00:50Z

r+

@fhahn I just realized you've been dutifully rebasing this PR and I didn't notice at all. I apologize for that. In any case, I think it seems clearly good!

nikomatsakis · 2015-04-18T09:00:59Z

(Unfortunately, it does need to be rebased again...)

fhahn · 2015-04-18T18:13:01Z

@nikomatsakis no worries, all rebases were very minimal & straightforward

pnkfelix · 2015-04-20T13:04:04Z

@bors r=nikomatsakis

bors · 2015-04-20T13:04:05Z

📌 Commit 2a24e97 has been approved by nikomatsakis

bors · 2015-04-20T13:20:20Z

⌛ Testing commit 2a24e97 with merge be9a72b...

At the moment, when compilation is stopped at a stop point (like `-Z parse-only`), `rustc` does not return an nonzero exit code even if there are errors (expect fatal ones, that cause it to panic immediately). As an example, compiling `src/test/compile-fail/doc-before-semi.rs` with `-Z parse-only` raises an error, but exists with 0. Note that I could not use `sess.abort_if_errors()` in the macro, because `sess` is passed by value and move at some point.

bors · 2015-04-20T15:23:50Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt

rust-highfive assigned nikomatsakis Feb 9, 2015

fhahn mentioned this pull request Feb 9, 2015
Move remaning compile-fail tests that are rejected by the parser to pars... #22118
Merged

fhahn force-pushed the fail-on-errors branch from c1cc39f to 476a3c6Compare February 13, 2015 22:28

fhahn force-pushed the fail-on-errors branch from 476a3c6 to 9e6190dCompare February 17, 2015 22:23

fhahn force-pushed the fail-on-errors branch from 9e6190d to e941932Compare February 22, 2015 22:25

fhahn force-pushed the fail-on-errors branch 2 times, most recently from be1ba0d to f29b4d7Compare March 7, 2015 19:56

fhahn force-pushed the fail-on-errors branch from f29b4d7 to 4397076Compare March 20, 2015 19:10

fhahn force-pushed the fail-on-errors branch from 4397076 to a4fdbb0Compare March 26, 2015 15:48

tamird reviewed Apr 5, 2015
View reviewed changes

Return nonzero exit code if there are errors at a stop point
2a24e97

fhahn force-pushed the fail-on-errors branch from a4fdbb0 to 2a24e97Compare April 18, 2015 18:11

bors merged commit 2a24e97 into rust-lang:masterApr 20, 2015

fhahn deleted the fail-on-errors branch April 20, 2015 20:14

Uh oh!

Uh oh!

Conversation

fhahn commented Feb 9, 2015

Uh oh!

rust-highfive commented Feb 9, 2015

Uh oh!

nikomatsakis commented Feb 9, 2015

Uh oh!

brson commented Feb 13, 2015

Uh oh!

fhahn commented Feb 13, 2015

Uh oh!

fhahn commented Feb 17, 2015

Uh oh!

fhahn commented Feb 22, 2015

Uh oh!

pczarn commented Mar 7, 2015

Uh oh!

fhahn commented Mar 7, 2015

Uh oh!

bors commented Mar 17, 2015

Uh oh!

fhahn commented Mar 20, 2015

Uh oh!

bors commented Mar 24, 2015

Uh oh!

fhahn commented Mar 26, 2015

Uh oh!

bors commented Apr 3, 2015

Uh oh!

tamirdApr 5, 2015

Choose a reason for hiding this comment

Uh oh!

nikomatsakis commented Apr 18, 2015

Uh oh!

nikomatsakis commented Apr 18, 2015

Uh oh!

fhahn commented Apr 18, 2015

Uh oh!

pnkfelix commented Apr 20, 2015

Uh oh!

bors commented Apr 20, 2015

Uh oh!

bors commented Apr 20, 2015

Uh oh!

bors commented Apr 20, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants