These passes were buggy, MIR building is now responsible for
canonicalizing `ConstantIndex` projections and `MoveData` is responsible
for splitting `Subslice` projections.
In which we implement illegal subset relations errors using Polonius
This PR is the rustc side of implementing subset errors using Polonius. That is, in
```rust
fn foo<'a, 'b>(x: &'a u32, y: &'b u32) -> &'a u32 {
y
}
```
returning `y` requires that `'b: 'a` but we have no evidence of that, so this is an error. (Evidence that the relation holds could come from explicit bounds, or via implied bounds).
Polonius outputs one such error per CFG point where the free region's placeholder loan unexpectedly flowed into another free region. While all these CFG locations could be useful in diagnostics in the future, rustc does not do that (and the duplication is only partially handled in the rest of the errors/diagnostics infrastructure, e.g. duplicate suggestions will be shown by the "outlives suggestions" or some of the `#[rustc_*]` NLL/MIR debug dumps), so I deduplicated the errors.
(The ordering also matters, otherwise some of the elided lifetime naming would change behaviour).
I've blessed a couple of tests, where the output is currently suboptimal:
- the `hrtb-perfect-forwarding` tests mix subset errors with higher-ranked subtyping, however the plan is for chalk to eventually take care of some of this to generate polonius constraints (i.e. it's not polonius' job). Until that happens, polonius will not see the error that NLL sees.
- some other tests have errors and diagnostics specific to `'static`, I _believe_ this to be because of it being treated as more "special" than in polonius. I believe the output is not wrong, but could be better, and appears elsewhere (I feel we'll need to look at polonius' handling of `'static` at some point in the future, maybe to match a bit more what NLL does when it produces errors)
I'll create a tracking issue in the polonius repo to record these 2 points (and a general "we'll need to go over the blessed output" issue, much like we did for NLLs)
The last blessed test is because it's an improvement: in this case, more errors/suggestions were computed, instead of the existing code path where this case apparently stops at the first error.
The `Naive` variant in Polonius computes those errors, so this PR also switches the default variant to that, as we're also in the process of temporarily deactivating all other variants (which exist mostly for performance considerations) until we have completed more work on completeness and correctness, before focusing on efficiency once again.
While most of the correctness in this PR is hidden in the polonius compare-mode (which of course passes locally), I've added a couple of smoke-tests to the existing ones, so that we have some confidence that it works (and keeps working) until we're in a position where we can run them on CI.
As mentioned during yesterday's wg-polonius meeting, @nikomatsakis has already read through most of this PR (and which is matching what they thought needed to be done [during the recent Polonius sprint](https://hackmd.io/CGMNjt1hR_qYtsR9hgdGmw#Compiler-notes-on-generating-the-placeholder-loans-support)), but Matthew was hopefully going to review (again, not urgent), so:
r? @matthewjasper
(This updates to the latest `polonius-engine` release, and I'm not sure whether `Cargo.lock` updates can easily be rolled up, but apart from that: this changes little that's tested on CI, so seems safe-ish to rollup ?)
Change unused_labels from allow to warn
Fixes#66324, making the unused_labels lint warn instead of allow by default. I'm told @rust-lang/lang will need to review this, and perhaps will want to do a crater run.
Miri core engine: use throw_ub instead of throw_panic
See https://github.com/rust-lang/rust/issues/66902 for context: panicking is not really an "interpreter error", but just part of a normal Rust execution. This is a first step towards removing the `InterpError::Panic` variant: the core Miri engine does not use it any more.
ConstProp and ConstEval still use it, though. This will be addressed in future PRs.
From what I can tell, all the error messages this removes are actually duplicates.
r? @oli-obk @wesleywiser
Emit coercion suggestions in more places
Fixes#66910
We have several different kinds of suggestions we can try to make when
type coercion fails. However, we were previously only emitting these
suggestions from `demand_coerce_diag`. This resulted in the compiler
failing to emit applicable suggestions in several different cases, such
as when the implicit return value of a function had the wrong type.
This commit adds a new `emit_coerce_suggestions` method, which tries to
emit a number of related suggestions. This method is called from both
`demand_coerce_diag` and `CoerceMany::coerce_inner`, which covers a much
wider range of cases than before.
We now suggest using `.await` in more cases where it is applicable,
among other improvements.
I'm not happy about disabling the `issue-59756`, but from what I can tell, the suggestion infrastructure in rustc lacks any way of indicating mutually exclusive suggestions (and compiletest lacks a way to only apply a subset of available suggestions).
Remove potential cfgs duplicates
Fixes https://github.com/rust-lang/rust/issues/66921.
Before going any further (the issue seems to be linked to metadata as far as I can tell). Do you think this is the good place to do it or should it be done before?
r? @eddyb
The polonius output has one more error which should be displayed
in the regular case, but error reporting in the regular case stopped
at the first error.
Admittedly it would be nice to combine suggestions for the same source
lifetime so that `'a: 'b` and `'a: 'c` are not bothsuggested, but instead
a single `'a: 'b + 'c` is.
Add long error for E0631 and update ui tests.
This PR adds a long error for `E0631`, which covers errors where closure argument types are mismatched. It also updates UI tests where this error is applicable.
Part of #61137
Make const-qualification look at more `const fn`s
As explained in a lot more detail in #67053 this makes const-qualification not ignore the unstable const fns in libcore.
r? @oli-obk cc @ecstatic-morse
(Still a bit unsure about the `cfg`s here, for bootstrapping, does that seem correct ?)
Fixes#67053.
Include a span in more `expected...found` notes
In most places, we use a span when emitting `expected...found` errors.
However, there were a couple of places where we didn't use any span,
resulting in hard-to-interpret error messages.
This commit attaches the relevant span to these notes, and additionally
switches over to using `note_expected_found` instead of manually
formatting the message
Make `process_obligations()` greedier.
`process_obligations()` adds new nodes, but it does not process these
new nodes until the next time it is called.
This commit changes it so that it does process these new nodes within
the same call. This change reduces the number of calls to
`process_obligations()` required to complete processing, sometimes
giving significant speed-ups.
The change required some changes to tests.
- The output of `cycle-cache-err-60010.rs` is slightly different.
- The unit tests required extra cases to handle the earlier processing
of the added nodes. I mostly did these in the simplest possible way,
by making the added nodes be ignored, thus giving outcomes the same as
with the old behaviour. But I changed `success_in_grandchildren()`
more extensively so that some obligations are completed earlier than
they used to be.
r? @nikomatsakis
