Skip to content

"aborting due to N previous errors" only counts errors in the last pass #33525

Closed
@arielb1

Description

@arielb1
Contributor

Meta

$ rustc --version
rustc 1.9.0-beta.1 (37a2869af 2016-04-12)

STR

fn main() {
    a;
    "".lorem;
    "".ipsum;
}

Expected Results

3 errors are reported, followed by "error: aborting due to 3 previous errors".

Actual Result

3 errors are reported, but the errors reported count only counts the 2 errors from the type-checking pass - so "error: aborting due to 2 previous errors" is printed.

Activity

added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Oct 11, 2016
nrc

nrc commented on Oct 11, 2016

@nrc
Member

Nominating just to signal boost really since this is really annoying. I think it should be easy to fix, but I'm not quite confident enough about that to slap an e-easy on this.

self-assigned this
on Oct 20, 2016
added
E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
on Oct 20, 2016
nikomatsakis

nikomatsakis commented on Oct 20, 2016

@nikomatsakis
Contributor

triage: P-medium

@nrc would love to mentor a fix. @nrc, if you can write up a series of steps to fix at some point that'd be great!

nrc

nrc commented on Oct 21, 2016

@nrc
Member

@Mark-Simulacrum were you interested in working on this?

Mark-Simulacrum

Mark-Simulacrum commented on Oct 21, 2016

@Mark-Simulacrum
Member

Sure! I'd be willing to try getting this done. Can you give me a hint where I should look at?

nrc

nrc commented on Oct 25, 2016

@nrc
Member

@Mark-Simulacrum

So, this is pretty much a "hunt the bug" issue. I'm not exactly sure where it is going wrong, but once you find it is should be easy to fix.

Start by looking at run_compiler in src/librustc_driver/lib.rs, this returns a CompileResult which if there is an error, contains the number of errors found. I'm 99% sure the problem is not actually in that function but in the tail call to driver::compile_input, that function executes each phase of the compiler. I think what is going on is that one phase has m errors, then we continue compilation (we didn't used to do this) and then a later stage has n errors and then we stop compilation returning n when we should return n + m. Once you've got a test case, it should be pretty easy to find where we're doing this. The slightly tricky bit is making sure we cover all possible cases for getting the wrong number of errors. Note that we can bail out of compilation from deep inside the phases. So it might be that at the top level, we track the number of errors, but deep in some phase we are giving up with only the error count from that phase or sub-phase.

Mark-Simulacrum

Mark-Simulacrum commented on Nov 11, 2016

@Mark-Simulacrum
Member

Okay, updating this issue with what I've found and putting it up for grabs, since I think this is more I-papercut and as such P-low, but I'll leave that designation up to the compiler team.

Currently, name resolution, for example, does not track the errors that it reports, and we then continue despite it's failure, forgetting to update the number of errors.

After talking with @nrc on IRC, it's been suggested that a semi-temporary fix for this could be to change the "error: aborting due to 3 previous errors" text to "error: aborting due to a few previous errors" for 2-4 errors, "error: aborting due to many previous errors" for 5+ errors, etc.

I personally feel like the error count isn't altogether that useful as it is, except potentially as a way of assessing the time required to remove an obsolete function or other wide-sweeping change--though I feel like rustc potentially not reporting all errors sort of makes even that not really possible; so perhaps the "right" fix is to remove the error reporting from the output, though that's technically backwards incompatible, I guess.

brson

brson commented on Nov 11, 2016

@brson
Contributor

I think the only value this message has is giving a concrete number, but it would be worth while to question how valuable that actually is. If we can't get the number right, then the message is not useful - it's obvious from the spew there were multiple errors of some quantity. I'd be happy removing it completely. We have a lot of error spew, and this is any easy bit to scale back.

14 remaining items

added 5 commits that reference this issue on May 24, 2017

Rollup merge of rust-lang#42150 - citizen428:feature/error-count-mess…

Rollup merge of rust-lang#42150 - citizen428:feature/error-count-mess…

Rollup merge of rust-lang#42150 - citizen428:feature/error-count-mess…

Rollup merge of rust-lang#42150 - citizen428:feature/error-count-mess…

Rollup merge of rust-lang#42150 - citizen428:feature/error-count-mess…

Mark-Simulacrum

Mark-Simulacrum commented on May 27, 2017

@Mark-Simulacrum
Member

This was fixed in #42150.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.P-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @citizen428@brson@nikomatsakis@nrc@arielb1

        Issue actions

          "aborting due to N previous errors" only counts errors in the last pass · Issue #33525 · rust-lang/rust