Introduce Lifetime::Error #809
Conversation
| @@ -555,14 +555,16 @@ bitflags! { | |||
| const HAS_CT_PROJECTION = 1 << 9; | |||
| /// Does the type contain an error | |||
| const HAS_ERROR = 1 << 10; | |||
| /// Does the type contain an error lifetime | |||
| const HAS_RE_ERROR = 1 << 11; | |||
There was a problem hiding this comment.
We need to differentiate between the two on the r-a side for filtering reasons wrt to diagnostics and assists
There was a problem hiding this comment.
Can you be more specific here? I'm not totally certain why RE_ERROR should be distinct f rom HAS_ERROR; the Rust compiler doesn't distinguish them, so this may complicate later unification.
There was a problem hiding this comment.
This is only needed temporarily until we have proper lifetime inference and elision as currently we only support 'static and named lifetimes. Because of that lack of inference and elision the majority of lifetimes will be error lifetimes which would cause us to discard a bunch of diagnostics (we discard them / not compute them on error containing types to not report too many follow up errors).
The bigger one being that exhaustiveness checking on anything containing an error lifetime will be skipped (and skipping an error containing type is required here as the exhaustiveness checking code is likely to panic otherwise).
So, it is not absolutely strictly needed, but it would be nice if we could carry this split for a bit until we have basic lifetime inference and elision implemented.
There was a problem hiding this comment.
Makes sense. I'm happy with this as long as we're okay with the temporary nature of the flag, and possibly more work for r-a to migrate off of this in the future (e.g. if r-a starts using rustc_type_ir, which does not make this distinction and I'm very certain we would not like to introduce this distinction to rustc_type_ir in the future).
|
r? @jackh726 |
|
@bors r+ |
|
☀️ Test successful - checks-actions |
r-a has some rudimentary lifetime support now, but due to the lack of an error variant we are using
Staticfor this right now. This results in worse UX as we now show'staticwhen it's actually some other possibly non'staticlifetime