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

Split delayed bugs into has-errored and will-error halves. #121016

Closed
wants to merge 2 commits into from

Conversation

nnethercote
Copy link
Contributor

Split delayed bugs into has-errored and will-error halves.

This commit adds new {span_,}assert_has_errors methods implementing the simpler has-errored cases, and leaves the existing {span_,}delayed_bug methods for the will-error cases.

It also converts as many cases as possible to has-errored. I did this by converting every case to has-errored, then running tests and converting back to will-error every case that caused an assertion in the test suite. The test suite doesn't have perfect coverage so it's possible that there are a few more has-errored cases that will need conversion back to will-error. Also, some of the will-error cases might actually be a mixture of has-errored and will-error. But it's hard to do this perfectly without carefully going through every individual case, which would be painful, and an imperfect split still gets most of the benefits.

r? @compiler-errors

@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Feb 13, 2024
@rustbot
Copy link
Collaborator

rustbot commented Feb 13, 2024

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Type relation code was changed

cc @compiler-errors, @lcnr

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred in const_evaluatable.rs

cc @BoxyUwU

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @TaKO8Ki

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

Some changes might have occurred in exhaustiveness checking

cc @Nadrieril

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@nnethercote
Copy link
Contributor Author

Only the fourth commit needs a review. The first three are from #120959 and #121015.

@@ -1089,7 +1089,7 @@ impl<'a, 'tcx> TypeChecker<'a, 'tcx> {
);

if result.is_err() {
Copy link
Contributor

Choose a reason for hiding this comment

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

just take the ErrorGuaranteed that is already there

Comment on lines -93 to +96
tcx.dcx()
.span_delayed_bug(attr.span, "this attribute can only be applied to functions");
tcx.dcx().span_assert_has_errors(
attr.span,
"this attribute can only be applied to functions",
);
Copy link
Contributor

Choose a reason for hiding this comment

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

The comment above talks about delayed bug, and it's not clear to me this will not be reachable by some random reordering of queries

Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

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

While I definitely want this split, I also think it's too messy to do this change in a (semi-)mechanical manner. Lots of these cases could just pass an ErrorGuaranteed along, and most others aren't clearly ICE free to me.

I think we should just add the scheme and use it to replace our existing has_errors().unwrap() calls, and then keep expanding its scope as we do cleanups.

@RalfJung
Copy link
Member

If we go with this as proposed, this seems worth some sort of MCP or so -- mostly for making as many people as possible aware that this happens so that when inevitably gaps in our test suite are discovered and more of these need to be converted to "will-error" cases, people already know that this is what happens (skipping potentially lengthy investigations) and can ping the right folks.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 13, 2024

I did this by converting every case to has-errored, then running tests and converting back to will-error every case that caused an assertion in the test suite.

My plan was the opposite 😅 check that a delay_span_bug is followed by an error, even if there were errors beforehand

@compiler-errors
Copy link
Member

r? oli-obk

@rustbot
Copy link
Collaborator

rustbot commented Feb 13, 2024

Assignment is not allowed on a closed PR.

@compiler-errors
Copy link
Member

whoops! sorry, misclick

r? oli-obk

@rustbot rustbot assigned oli-obk and unassigned compiler-errors Feb 13, 2024
@bors
Copy link
Contributor

bors commented Feb 13, 2024

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

Once we have emitted at least one error, delayed bugs won't be used. So
we can (a) we can (a) discard any existing delayed bugs, and (b) stop
recording any new delayed bugs.

This eliminates a longstanding `FIXME` comment. There should be no
soundness issues because it's not possible to un-emit an error.
This commit adds new `{span_,}assert_has_errors` methods implementing
the simpler has-errored cases, and leaves the existing
`{span_,}delayed_bug` methods for the will-error cases.

It also converts as many cases as possible to has-errored. I did this by
converting every case to has-errored, then running tests and converting
back to will-error every case that caused an assertion in the test
suite. The test suite doesn't have perfect coverage so it's possible
that there are a few more has-errored cases that will need conversion
back to will-error. Also, some of the will-error cases might actually be
a mixture of has-errored and will-error. But it's hard to do this
perfectly without carefully going through every individual case, which
would be painful, and an imperfect split still gets most of the
benefits.
@nnethercote
Copy link
Contributor Author

There are about 200 delayed bug uses and about 2/3 of them can be converted to assert_has_errors without causing any tests to fail. A crater run would likely show up a few more failures, but it seems like the majority of the delayed bugs are not truly necessary. And if we don't have some kind of semi-mechanical way to convert them, we're likely to end up with lots of unnecessary delayed bugs, i.e. not much change from the status quo.

Nonetheless, I've filed #121071. It doesn't add any new assert_has_errors methods, it just uses assert!(dcx.has_errors()), which is equivalent. And I've only converted delayed bugs that were obviously unnecessary, there are about 20 of them. So, much smaller/weaker than this PR, but also less controversial.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 14, 2024

My worry is that when we make rustc more parallel we'll end up with lots of ICEs where we previously had a guaranteed order.

@bors
Copy link
Contributor

bors commented Feb 14, 2024

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

@nnethercote
Copy link
Contributor Author

Closing in favour of #121071.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants