| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
When encountering an unmet trait bound, point at local type that doesn't implement the trait:
```
error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied
--> $DIR/issue-64855.rs:9:19
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Foo` is not implemented for `Bar<T>`
--> $DIR/issue-64855.rs:9:1
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^
```
|
|
In rustc it doesn't really matter what the order of the witnesses is, but I'm planning to use the witnesses for implementing the "add missing match arms" assist in rust-analyzer, and there `true` before `false` is the natural order (like `Some` before `None`), and also what the current assist does.
The current order doesn't seem to be intentional; the code was created when bool ctors became their own thing, not just int ctors, but for integer, 0 before 1 is indeed the natural order.
|
|
Without adding proper support for mixed exhaustiveness, mixing deref
patterns with normal constructors would either violate
`ConstructorSet::split`'s invariant 4 or 7. We'd either be ignoring rows
with normal constructors or we'd have problems in unspecialization from
non-disjoint constructors. Checking mixed exhaustivenss similarly to how
unions are currently checked should work, but the diagnostics for unions
are confusing. Since mixing deref patterns with normal constructors is
pretty niche (currently it only makes sense for `Cow`), emitting an
error lets us avoid committing to supporting mixed exhaustiveness
without a good answer for the diagnostics.
|
|
|
|
This does not yet handle the case of mixed deref patterns with normal
constructors; it'll ICE in `Constructor::is_covered_by`. That'll be
fixed in a later commit.
|
|
|
|
|
|
|
|
|
|
This allows deref patterns to move out of boxes.
Implementation-wise, I've opted to put the information of whether a
deref pattern uses a built-in deref or a method call in the THIR. It'd
be a bit less code to check `.is_box()` everywhere, but I think this way
feels more robust (and we don't have a `mutability` field in the THIR
that we ignore when the smart pointer's a box). I'm not sure about the
naming (or using `ByRef`), though.
|
|
Since deref patterns on boxes will be lowered differently, I'll be
making a separate test file for them. This makes sure we're still
testing the generic `Deref(Mut)::deref(_mut)`-based lowering.
|
|
Specifically, this allows byte string literal patterns to be used where
a `[u8]` or `[u8;N]` is expected when `deref_patterns` is enabled.
|
|
Specifically, this allows string literal patterns to be used where a
`str` is expected when `deref_patterns` is enabled.
|
|
|
|
Implicit deref patterns allow previously ill-typed programs. Make sure
they're still ill-typed without the feature gate. I've thrown in a test
for `deref!(_)` too, though it seems it refers to `deref_patterns` as a
library feature.
|
|
|
|
|
|
This is the use for the previous commits' refactors; see the messages
there for more information.
|
|
|
|
|
|
The place previously used here was that of the temporary holding the
reference returned by `Deref::deref` or `DerefMut::deref_mut`. However,
since the inner pattern of `deref!(inner)` expects the deref-target type
itself, this would ICE when that type was inspected (e.g. by the EUV
case for slice patterns). This adds a deref projection to fix that.
Since current in-tree consumers of EUV (upvar inference and clippy)
don't care about Rvalues, the place could be simplified to
`self.cat_rvalue(pat.hir_id, self.pat_ty_adjusted(subpat)?)` to save
some cycles. I personally find EUV to be a bit fragile, so I've opted
for pedantic correctness. Maybe a `HACK` comment would suffice though?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This handles using deref patterns to choose the correct match arm. This
does not handle bindings or guards.
Co-authored-by: Deadbeef <ent3rm4n@gmail.com>
|
|
|
|
Stop using `box PAT` syntax for deref patterns, as it's misleading and
also causes their semantics being tangled up.
|
|
Co-authored-by: Deadbeef <ent3rm4n@gmail.com>
|
