Delay specific span_bug() call until abort_if_errors() #24367

ebfull · 2015-04-13T08:17:46Z

An actual typeck error is the cause of many failed compilations but an
unrelated bug is being reported instead. It is triggered because a typeck
error is presumably not yet identified during compiler execution, which
would normally bypass an invariant in the presence of other errors. In
this particular situation, we delay the reporting of the bug until
abort_if_errors().

Closes #23827, closes #24356, closes #23041, closes #22897, closes #23966,
closes #24013, and closes #23729

There is at least one situation where this bug may still be genuinely
triggered (#23437).

An actual typeck error is the cause of many failed compilations but an unrelated bug is being reported instead. It is triggered because a typeck error is presumably not yet identified during compiler execution, which would normally bypass an invariant in the presence of other errors. In this particular situation, we delay the reporting of the bug until abort_if_errors(). Closes rust-lang#23827, closes rust-lang#24356, closes rust-lang#23041, closes rust-lang#22897, closes rust-lang#23966, closes rust-lang#24013, and closes rust-lang#23729

rust-highfive · 2015-04-13T08:18:00Z

r? @alexcrichton

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

ebfull · 2015-04-13T08:18:19Z

r? @pnkfelix

pnkfelix · 2015-04-13T10:47:33Z

src/librustc_typeck/check/regionck.rs

@@ -544,7 +544,7 @@ fn visit_expr(rcx: &mut Rcx, expr: &ast::Expr) {
                if tcx.sess.has_errors() {
                    // cannot run dropck; okay b/c in error state anyway.
                } else {
-                    tcx.sess.span_bug(expr.span, "cat_expr_unadjusted Errd");
+                    tcx.sess.delay_span_bug(expr.span, "cat_expr Errd");


don't change the message here; it is still a call to cat_expr_unadjusted up above, which is info I wanted to capture in the ICE message.

pnkfelix · 2015-04-13T10:48:52Z

My reasoning behind calling span_bug in the first place was that I wanted to be notified about cases where the call to cat_expr is err'ing.

I guess as long as such cases continue to emit an ICE, then its not wrong to make this change.

But I wonder if it might be simpler (and more correct) to try to identify an earlier spot in the control flow to add an additional call to abort_if_errors.

Update: Of course there is also the option of doing both; i.e. land this PR now, but also try to fix the ICE itself by finding a new place (or more) to call abort_if_errors.

Update 2: Adding earlier calls to abort_if_errors won't fix things, both for the reason outlined down below (that I transcribed from @arielb1) but also because the code path in question is already checking if the tcx.sess has reported any errors anyway.

pnkfelix · 2015-04-13T13:01:05Z

@arielb1 points out that inserting a new call to abort_if_errors would not be ideal, since it will continue to cause us to abort, when we really want to allow compilation to keep going and find more (independent) errors

The real problem here, @arielb1 points out, is that the guard on the span_bug here is only checking the tcx.sess to see if any errors have been emitted, but the fcx itself may also have errors registered that are not reflected in the tcx.sess.

Update: On further investigation, I am not 100% sure the analysis in this comment is quite right. E.g. I do not yet see how one can have errors registered in the fcx that are not reflected in the tcx.sess; stay tuned...

pnkfelix · 2015-04-13T14:06:55Z

Actually, another potential way to go here would be to use the same strategy employed in this PR, except with the refinement that the Some arm for the match *delayed_bug should only ICE if !self.diagnostic().handler().has_errors().

That is, if we did end up reporting at least one error, then we could just say "okay, lets pretend that was the error that caused cat_expr to Err.

(Though I do worry about the potential for circular reasoning here, where a cat_expr Err that has gone undetected could then yield a spurious error downstream, and then that's reported, but is useless to the user and at the same time we get no ICE bug report...)

ebfull · 2015-04-13T15:04:18Z

Actually, another potential way to go here would be to use the same strategy employed in this PR, except with the refinement that the Some arm for the match *delayed_bug should only ICE if !self.diagnostic().handler().has_errors().
That is, if we did end up reporting at least one error, then we could just say "okay, lets pretend that was the error that caused cat_expr to Err.

If I'm reading your comment right, that's what the code currently does. It should abort before the match *delayed_bug if there are any errors.

arielb1 · 2015-04-13T19:58:58Z

I say remove the tcx.sess.has_errors() check in that case. The worst case here is that we get crazy lifetime errors.

ebfull · 2015-04-13T20:21:10Z

Done with both your recommendations, but it'd be nicer if these ICEs can be avoided by changing mem_categorization somehow.

pnkfelix · 2015-04-13T21:16:53Z

@ebfull after discussion with @arielb1 on IRC, I think we can indeed avoid many of the ICE's, not by changing mem_categorization, but rather by restructuring the type checker to do high-level signature-matching checks (e.g. that trait impls define all necessary items from the trait definitions) before checking any bodies. I have a prototype that does that in development right now.

We may indeed still want to put in this PR, but i am not certain of that yet; I, like you, would prefer to get rid of this ICE entirely. (And indeed, the path to get there may still involve changes to mem_categorization; I am not sure yet.)

pnkfelix · 2015-04-14T12:01:25Z

@ebfull btw you were correct when you wrote:

If I'm reading your comment right, that's what the code currently does. It should abort before the match *delayed_bug if there are any errors.

that is, my comment was based on a misreading of your code.

Update: fixed typo where I mistyped @ebfull 's username.

pnkfelix · 2015-04-14T16:57:13Z

I have opened #24422 , which adopts the strategy outlined in an earlier comment.

However, it does not address all of the ICE's listed in this ticket. So we may still indeed want to adopt this change. I will look into it.

ebull · 2015-04-14T19:33:42Z

@pnkfelix ebfull != ebull :)

From: Felix S Klock II [email protected]
Sent: Tuesday, April 14, 2015 12:57 PM
To: rust-lang/rust
Cc: ebull
Subject: Re: [rust] Delay specific span_bug() call until abort_if_errors() (#24367)

I have opened #24422 #24422 , which adopts the strategy outlined in an earlier comment.

[https://avatars3.githubusercontent.com/u/173127?v=3&s=400]#24422

Typeck highlevel before bodies by pnkfelix · Pull Request #24422 · rust-lang/rust · GitHub
typeck: Do high-level structural/signature checks before function body checks. This avoids various ICEs, e.g. premature calls to cat_expr that yield the dreaded "cat_expr Errd" ICE. However, it also means that some early error feedback...
Read more...#24422

However, it does not address all of the ICE's listed in this ticket. So we may still indeed want to adopt this change. I will look into it.

Reply to this email directly or view it on GitHubhttps://github.com//pull/24367#issuecomment-92979142.

huonw · 2015-04-23T12:30:29Z

r? @pnkfelix (fell through the cracks?)

pnkfelix · 2015-04-23T20:50:26Z

@huonw well, i was half-hoping to find a way to fix all of the known ICE's without adopting the strategy outlined in this PR. But its probably a better plan to adopt it at this point.

pnkfelix · 2015-04-23T20:54:32Z

src/test/compile-fail/typeck-before-dropck-bug.rs

+
+fn unconstrained_type() {
+    [];
+    //~^ ERROR cannot determine a type for this expression: unconstrained type


@ebfull you'll need to update the test; the compiler has changed now with #24422 so that this error message is no longer emitted (since the problem in the impl below is signaled first).

ebfull · 2015-04-24T18:36:58Z

Done, I stopped testing against what you fixed in #24422 as well.

pnkfelix · 2015-04-25T09:31:43Z

@bors r+ be11171 rollup

bors · 2015-04-25T11:50:42Z

⌛ Testing commit be11171 with merge 7765aed...

bors · 2015-04-25T13:10:32Z

💔 Test failed - auto-mac-32-opt

alexcrichton · 2015-04-25T17:34:29Z

@bors: retry

On Sat, Apr 25, 2015 at 6:10 AM, bors [email protected] wrote:

[image: 💔] Test failed - auto-mac-32-opt
http://buildbot.rust-lang.org/builders/auto-mac-32-opt/builds/4695

—
Reply to this email directly or view it on GitHub
#24367 (comment).

bors · 2015-04-25T20:51:41Z

⌛ Testing commit be11171 with merge b01ed84...

bors · 2015-04-25T21:44:49Z

💔 Test failed - auto-linux-64-nopt-t

pnkfelix · 2015-04-26T05:18:18Z

@bors retry

bors · 2015-04-26T05:32:17Z

⌛ Testing commit be11171 with merge b0043db...

An actual typeck error is the cause of many failed compilations but an unrelated bug is being reported instead. It is triggered because a typeck error is presumably not yet identified during compiler execution, which would normally bypass an invariant in the presence of other errors. In this particular situation, we delay the reporting of the bug until abort_if_errors(). Closes #23827, closes #24356, closes #23041, closes #22897, closes #23966, closes #24013, and closes #23729 **There is at least one situation where this bug may still be genuinely triggered (#23437).**

bors · 2015-04-26T07:27:47Z

☀️ 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

ebfull · 2015-04-26T07:28:58Z

Should this be backported to beta like #24422?

pnkfelix · 2015-04-26T09:45:47Z

triage: beta-nominated

(I am personally on fence, but it is worth discussing)

pnkfelix · 2015-04-30T21:10:38Z

not accepted for beta backport.

rust-highfive assigned alexcrichton Apr 13, 2015

rust-highfive assigned pnkfelix and unassigned alexcrichton Apr 13, 2015

pnkfelix reviewed Apr 13, 2015
View reviewed changes

Leave error message intact

c660609

Completely delay this error checking

8f41b74

pnkfelix reviewed Apr 23, 2015
View reviewed changes

Split up tests, reduce coverage

be11171

bors merged commit be11171 into rust-lang:master Apr 26, 2015

rust-highfive added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 26, 2015

pnkfelix removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 30, 2015

pnkfelix mentioned this pull request May 4, 2015

ICE that can only be reproduced on playbot/play.rust-lang.org: casting a shared reference to a *const to a *mut _ (lack of type required) #25086

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Delay specific span_bug() call until abort_if_errors() #24367

Delay specific span_bug() call until abort_if_errors() #24367

ebfull commented Apr 13, 2015

rust-highfive commented Apr 13, 2015

ebfull commented Apr 13, 2015

pnkfelix Apr 13, 2015

pnkfelix commented Apr 13, 2015

pnkfelix commented Apr 13, 2015

pnkfelix commented Apr 13, 2015

ebfull commented Apr 13, 2015

arielb1 commented Apr 13, 2015

ebfull commented Apr 13, 2015

pnkfelix commented Apr 13, 2015

pnkfelix commented Apr 14, 2015

pnkfelix commented Apr 14, 2015

ebull commented Apr 14, 2015

huonw commented Apr 23, 2015

pnkfelix commented Apr 23, 2015

pnkfelix Apr 23, 2015

ebfull commented Apr 24, 2015

pnkfelix commented Apr 25, 2015

bors commented Apr 25, 2015

bors commented Apr 25, 2015

alexcrichton commented Apr 25, 2015

bors commented Apr 25, 2015

bors commented Apr 25, 2015

pnkfelix commented Apr 26, 2015

bors commented Apr 26, 2015

bors commented Apr 26, 2015

ebfull commented Apr 26, 2015

pnkfelix commented Apr 26, 2015

pnkfelix commented Apr 30, 2015

Delay specific span_bug() call until abort_if_errors() #24367

Delay specific span_bug() call until abort_if_errors() #24367

Conversation

ebfull commented Apr 13, 2015

rust-highfive commented Apr 13, 2015

ebfull commented Apr 13, 2015

pnkfelix Apr 13, 2015

Choose a reason for hiding this comment

pnkfelix commented Apr 13, 2015

pnkfelix commented Apr 13, 2015

pnkfelix commented Apr 13, 2015

ebfull commented Apr 13, 2015

arielb1 commented Apr 13, 2015

ebfull commented Apr 13, 2015

pnkfelix commented Apr 13, 2015

pnkfelix commented Apr 14, 2015

pnkfelix commented Apr 14, 2015

ebull commented Apr 14, 2015

huonw commented Apr 23, 2015

pnkfelix commented Apr 23, 2015

pnkfelix Apr 23, 2015

Choose a reason for hiding this comment

ebfull commented Apr 24, 2015

pnkfelix commented Apr 25, 2015

bors commented Apr 25, 2015

bors commented Apr 25, 2015

alexcrichton commented Apr 25, 2015

bors commented Apr 25, 2015

bors commented Apr 25, 2015

pnkfelix commented Apr 26, 2015

bors commented Apr 26, 2015

bors commented Apr 26, 2015

ebfull commented Apr 26, 2015

pnkfelix commented Apr 26, 2015

pnkfelix commented Apr 30, 2015