Skip to content

Remove FIXME since there is nothing to be fixed - #89907

Merged
bors merged 1 commit into
rust-lang:masterfrom
GuillaumeGomez:correctly-emit-errors
Oct 17, 2021
Merged

Remove FIXME since there is nothing to be fixed#89907
bors merged 1 commit into
rust-lang:masterfrom
GuillaumeGomez:correctly-emit-errors

Conversation

@GuillaumeGomez

@GuillaumeGomezGuillaumeGomez commented Oct 15, 2021

Copy link
Copy Markdown
Member

Resolves#88593.

The errors are deduplicated when displayed to users. They only appear
multiple times in UI tests.

cc @jyn514
r? @camelid

@GuillaumeGomezGuillaumeGomez added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. A-diagnostics Area: Messages for errors, warnings, and lints A-error-handling Area: Error handling labels Oct 15, 2021
@rust-highfiverust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 15, 2021

@jyn514jyn514 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't looked at the test case, but the abort_if_errors() call looks right.

@camelid

Copy link
Copy Markdown
Member

It has one downsize though: rustdoc errors are now run in a "different pass", which I find not great...

What does this mean? Do you mean that if there was a rustc error, no rustdoc errors will be reported until the rustc error is fixed?

@GuillaumeGomez

Copy link
Copy Markdown
MemberAuthor

Exactly. For example, in the test I splitted in two parts, it's because the rustdoc lints weren't emitted because we aborted before them.

@Mark-Simulacrum

Copy link
Copy Markdown
Member

rustc itself generally deduplicates errors, that's just turned off for UI tests. Does this duplication reproduce outside of UI tests? If not, it may be preferable to avoid the early abort, which we're generally trying to move away from where possible.

Comment threadsrc/librustdoc/core.rs Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
tcx.sess.abort_if_errors();
// Avoid emitting duplicate errors later on.
tcx.sess.abort_if_errors();

Comment on lines 1 to 2

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is unrelated to this change, but why did it not emit missing_docs for the crate before?

Seems like the situation is this:

Before

  • function

After

  • crate
  • function

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rustc lint passes come afterwards (unless I missed something?).

@camelid

Copy link
Copy Markdown
Member

rustc itself generally deduplicates errors, that's just turned off for UI tests. Does this duplication reproduce outside of UI tests? If not, it may be preferable to avoid the early abort, which we're generally trying to move away from where possible.

Huh, you're right; it doesn't seem to reproduce outside of UI tests. I thought I had found it "in the wild", but perhaps not.

@camelid

Copy link
Copy Markdown
Member

I guess this PR and associated issue can be closed then?

@camelid

Copy link
Copy Markdown
Member

Or maybe just repurpose this PR so it removes the FIXME in the test.

@GuillaumeGomez

Copy link
Copy Markdown
MemberAuthor

As you prefer. I personally don't have preference here. Just like the borrow checker comes after the other checks, I don't see it abnormal to have the rustdoc checks only if rustc is happy.

@camelid

camelid commented Oct 15, 2021

Copy link
Copy Markdown
Member

As you prefer. I personally don't have preference here. Just like the borrow checker comes after the other checks, I don't see it abnormal to have the rustdoc checks only if rustc is happy.

It'd be better to have as many errors as possible be reported in one build, as long as none are spurious. So I don't see why we should add this early abort, especially if T-compiler (or whichever team Mark was referring to) is moving away from it.

The borrow checker not running if earlier stages failed is just a technical limitation IIUC.

@GuillaumeGomez

Copy link
Copy Markdown
MemberAuthor

Then I'll update the PR to remove the FIXME. :)

@GuillaumeGomez

Copy link
Copy Markdown
MemberAuthor

And done!

@camelidcamelid changed the title Abort when error happens and not later onRemove FIXME since there is nothing to be fixedOct 16, 2021
@camelid

Copy link
Copy Markdown
Member

r=me with the commit message amended to include something like this:

The errors are deduplicated when displayed to users. They only appear
multiple times in UI tests.

@camelidcamelid added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 16, 2021
The errors are deduplicated when displayed to users. They only appear
multiple times in UI tests.
@GuillaumeGomez

Copy link
Copy Markdown
MemberAuthor

Done!

@GuillaumeGomezGuillaumeGomez added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 16, 2021
@camelid

Copy link
Copy Markdown
Member

Thanks!

@bors r+ rollup

@bors

bors commented Oct 16, 2021

Copy link
Copy Markdown
Collaborator

📌 Commit 7bad85e has been approved by camelid

@borsbors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 16, 2021
@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 16, 2021
@GuillaumeGomez
GuillaumeGomezforce-pushed the correctly-emit-errors branch 2 times, most recently from 629ec2a to 7bad85eCompareOctober 16, 2021 20:33
@camelid

Copy link
Copy Markdown
Member

@bors r+

@bors

bors commented Oct 16, 2021

Copy link
Copy Markdown
Collaborator

📌 Commit 7bad85e has been approved by camelid

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Oct 16, 2021
…s, r=camelid
Remove FIXME since there is nothing to be fixed
Resolvesrust-lang#88593.
The errors are deduplicated when displayed to users. They only appear
multiple times in UI tests.
cc `@jyn514`
r? `@camelid`
@JohnTitorJohnTitor mentioned this pull request Oct 16, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 17, 2021
Rollup of 7 pull requests
Successful merges:
- rust-lang#89507 (Add `#[repr(i8)]` to `Ordering`)
- rust-lang#89849 (CI: Selecting the Xcode version no longer needed with the macos-11 runners.)
- rust-lang#89886 (Update the wasi-libc built with the wasm32-wasi target)
- rust-lang#89907 (Remove FIXME since there is nothing to be fixed)
- rust-lang#89943 (clippy::complexity fixes)
- rust-lang#89953 (Make Option::as_mut const)
- rust-lang#89958 (Correct small typo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
@bors
bors merged commit c393f33 into rust-lang:masterOct 17, 2021
@rustbotrustbot added this to the 1.57.0 milestone Oct 17, 2021
@GuillaumeGomez
GuillaumeGomez deleted the correctly-emit-errors branch October 17, 2021 10:41
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsA-error-handlingArea: Error handlingS-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

rustdoc reports error twice for ambiguous (inherent) associated type

7 participants

@GuillaumeGomez@camelid@Mark-Simulacrum@bors@jyn514@rust-highfive@rustbot