Commit Graph

55 Commits

Author SHA1 Message Date
bors
9bb6e60d1f Auto merge of #103695 - LYF1999:yf/103563, r=lcnr
fix: Unexpected trait bound not satisfied in HRTB and Associated Type

fix https://github.com/rust-lang/rust/issues/103563
2023-02-14 10:01:19 +00:00
Michael Goulet
e20f6ff1dc Tighter spans for bad inherent impl types 2023-02-13 18:41:18 +00:00
yifei
d164448038 fix: Unexpected trait bound not satisfied in HRTB 2023-02-13 19:39:44 +08:00
bors
71f6675de1 Auto merge of #107919 - Dylan-DPC:rollup-fkl9swa, r=Dylan-DPC
Rollup of 9 pull requests

Successful merges:

 - #105019 (Add parentheses properly for borrowing suggestion)
 - #106001 (Stop at the first `NULL` argument when iterating `argv`)
 - #107098 (Suggest function call on pattern type mismatch)
 - #107490 (rustdoc: remove inconsistently-present sidebar tooltips)
 - #107855 (Add a couple random projection tests for new solver)
 - #107857 (Add ui test for implementation on projection)
 - #107878 (Clarify `new_size` for realloc means bytes)
 - #107888 (revert #107074, add regression test)
 - #107900 (Zero the `REPARSE_MOUNTPOINT_DATA_BUFFER` header)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2023-02-11 09:19:07 +00:00
Michael Goulet
9790d6fbdd Add a couple random projection tests 2023-02-10 18:14:09 +00:00
Boxy
4c98429d8c Add tests 2023-02-10 14:56:28 +00:00
Michael Goulet
3c4e1f85cb Multiple candidates with same response is not ambiguous 2023-02-10 00:35:25 +00:00
Dylan DPC
b080a1a4fc
Rollup merge of #107815 - compiler-errors:new-solver-no-auto-if-impl, r=lcnr
Disqualify `auto trait` built-in impl in new solver if explicit `impl` exists
2023-02-09 23:18:37 +05:30
Dylan DPC
16a4138387
Rollup merge of #107803 - eggyal:do_not_bring_trait_alias_supertraits_into_scope, r=compiler-errors
Do not bring trait alias supertraits into scope

Fixes #107747
cc #41517
2023-02-09 23:18:36 +05:30
Michael Goulet
68e27b3052 Disqualify auto-trait builtin impl in new solver if impl exists 2023-02-09 17:23:50 +00:00
Michael Goulet
8987e68247 Implement a dummy drop-in-favor-of for the new solver 2023-02-09 17:22:37 +00:00
Michael Goulet
8c67ecd124 Use elaborated item bounds for alias types 2023-02-09 17:16:47 +00:00
Alan Egerton
38ec810c37
Do not assemble supertraits for trait aliases 2023-02-08 19:55:50 +00:00
lcnr
4c7c5e597f add (currently ICEing) test 2023-02-08 19:11:14 +01:00
Michael Goulet
2b70cbb8a5 Rename PointerSized to PointerLike 2023-02-07 19:05:53 +00:00
Matthias Krüger
800221b5b8
Rollup merge of #106477 - Nathan-Fenner:nathanf/refined-error-span-trait-impl, r=compiler-errors
Refine error spans for "The trait bound `T: Trait` is not satisfied" when passing literal structs/tuples

This PR adds a new heuristic which refines the error span reported for "`T: Trait` is not satisfied" errors, by "drilling down" into individual fields of structs/enums/tuples to point to the "problematic" value.

Here's a self-contained example of the difference in error span:

```rs
struct Burrito<Filling> {
    filling: Filling,
}
impl <Filling: Delicious> Delicious for Burrito<Filling> {}
fn eat_delicious_food<Food: Delicious>(food: Food) {}
fn will_type_error() {
    eat_delicious_food(Burrito { filling: Kale });
    //                 ^~~~~~~~~~~~~~~~~~~~~~~~~ (before) The trait bound `Kale: Delicious` is not satisfied
    //                                    ^~~~   (after)  The trait bound `Kale: Delicious` is not satisfied
}
```
(kale is fine, this is just a silly food-based example)

Before this PR, the error span is identified as the entire argument to the generic function `eat_delicious_food`. However, since only `Kale` is the "problematic" part, we can point at it specifically. In particular, the primary error message itself mentions the missing `Kale: Delicious` trait bound, so it's much clearer if this part is called out explicitly.

---

The _existing_ heuristic tries to label the right function argument in `point_at_arg_if_possible`. It goes something like this:
- Look at the broken base trait `Food: Delicious` and find which generics it mentions (in this case, only `Food`)
- Look at the parameter type definitions and find which of them mention `Filling` (in this case, only `food`)
- If there is exactly one relevant parameter, label the corresponding argument with the error span, instead of the entire call

This PR extends this heuristic by further refining the resulting expression span in the new `point_at_specific_expr_if_possible` function. For each `impl` in the (broken) chain, we apply the following strategy:

The strategy to determine this span involves connecting information about our generic `impl`
with information about our (struct) type and the (struct) literal expression:
- Find the `impl` (`impl <Filling: Delicious> Delicious for Burrito<Filling>`)
  that links our obligation (`Kale: Delicious`) with the parent obligation (`Burrito<Kale>: Delicious`)
- Find the "original" predicate constraint in the impl (`Filling: Delicious`) which produced our obligation.
- Find all of the generics that are mentioned in the predicate (`Filling`).
- Examine the `Self` type in the `impl`, and see which of its type argument(s) mention any of those generics.
- Examing the definition for the `Self` type, and identify (for each of its variants) if there's a unique field
  which uses those generic arguments.
- If there is a unique field mentioning the "blameable" arguments, use that field for the error span.

Before we do any of this logic, we recursively call `point_at_specific_expr_if_possible` on the parent
obligation. Hence we refine the `expr` "outwards-in" and bail at the first kind of expression/impl we don't recognize.

This function returns a `Result<&Expr, &Expr>` - either way, it returns the `Expr` whose span should be
reported as an error. If it is `Ok`, then it means it refined successfull. If it is `Err`, then it may be
only a partial success - but it cannot be refined even further.

---

I added a new test file which exercises this new behavior. A few existing tests were affected, since their error spans are now different. In one case, this leads to a different code suggestion for the autofix - although the new suggestion isn't _wrong_, it is different from what used to be.

This change doesn't create any new errors or remove any existing ones, it just adjusts the spans where they're presented.

---

Some considerations: right now, this check occurs in addition to some similar logic in `adjust_fulfillment_error_for_expr_obligation` function, which tidies up various kinds of error spans (not just trait-fulfillment error). It's possible that this new code would be better integrated into that function (or another one) - but I haven't looked into this yet.

Although this code only occurs when there's a type error, it's definitely not as efficient as possible. In particular, there are definitely some cases where it degrades to quadratic performance (e.g. for a trait `impl` with 100+ generic parameters or 100 levels deep nesting of generic types). I'm not sure if these are realistic enough to worry about optimizing yet.

There's also still a lot of repetition in some of the logic, where the behavior for different types (namely, `struct` vs `enum` variant) is _similar_ but not the same.

---

I think the biggest win here is better targeting for tuples; in particular, if you're using tuples + traits to express variadic-like functions, the compiler can't tell you which part of a tuple has the wrong type, since the span will cover the entire argument. This change allows the individual field in the tuple to be highlighted, as in this example:

```
// NEW
LL |     want(Wrapper { value: (3, q) });
   |     ----                      ^ the trait `T3` is not implemented for `Q`

// OLD
LL |     want(Wrapper { value: (3, q) });
   |     ---- ^~~~~~~~~~~~~~~~~~~~~~~~~ the trait `T3` is not implemented for `Q`
```
Especially with large tuples, the existing error spans are not very effective at quickly narrowing down the source of the problem.
2023-02-06 21:16:39 +01:00
bors
f361413cbf Auto merge of #106399 - estebank:type-err-span-label, r=nagisa
Modify primary span label for E0308

Looking at the reactions to https://hachyderm.io/`@ekuber/109622160673605438,` a lot of people seem to have trouble understanding the current output, where the primary span label on type errors talks about the specific types that diverged, but these can be deeply nested type parameters. Because of that we could see "expected i32, found u32" in the label while the note said "expected Vec<i32>, found Vec<u32>". This understandably confuses people. I believe that once people learn to read these errors it starts to make more sense, but this PR changes the output to be more in line with what people might expect, without sacrificing terseness.

Fix #68220.
2023-01-31 13:53:40 +00:00
Esteban Küber
62ba3e70a1 Modify primary span label for E0308
The previous output was unintuitive to users.
2023-01-30 20:12:19 +00:00
Michael Goulet
c24844048f Trait upcasting support in new solver 2023-01-30 19:11:01 +00:00
Michael Goulet
085a48e798 Implement unsizing in the new trait solver 2023-01-30 19:11:01 +00:00
bors
d117135f5a Auto merge of #106253 - nbdd0121:upcast, r=compiler-errors
Skip possible where_clause_object_safety lints when checking `multiple_supertrait_upcastable`

Fix #106247

To achieve this, I lifted the `WhereClauseReferencesSelf` out from `object_safety_violations` and move it into `is_object_safe` (which is changed to a new query).

cc `@dtolnay`
r? `@compiler-errors`
2023-01-29 10:20:25 +00:00
Gary Guo
66f3ab90a1 Reintroduce multiple_supertrait_upcastable lint 2023-01-28 15:08:07 +00:00
Yuki Okushi
dbe911ff36
Add regression test for #60755
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
2023-01-27 19:46:56 +09:00
Michael Goulet
d600b94ebb Implement Generator and Future 2023-01-26 03:15:36 +00:00
Matthias Krüger
a20b86f881
Rollup merge of #107282 - BoxyUwU:erica_builtin_pointee_impls, r=compiler-errors
erica solver: implement builtin `Pointee` trait impl candidates

r? ```@compiler-errors```
2023-01-25 22:19:56 +01:00
Matthias Krüger
9e3f330656
Rollup merge of #106897 - estebank:issue-99430, r=davidtwco
Tweak E0597

CC #99430
2023-01-25 22:19:52 +01:00
Boxy
430dab0b42 implement builtin candidate 2023-01-24 23:24:30 +00:00
Nathan Fenner
2a67e99d7d Point at specific field in struct literal when trait fulfillment fails 2023-01-23 13:37:58 -08:00
Santiago Pastorino
b905f80036
fn-trait-closure test now pass on new solver 2023-01-22 12:36:58 -03:00
Michael Goulet
3452104715
Rollup merge of #107061 - compiler-errors:new-solver-new-candidates-3, r=lcnr
Implement some more new solver candidates and fix some bugs

First, fix some bugs:

1. `IndexVec::drain_enumerated(a..b)` does not give us an iterator of index keys + items enumerated from `a..b`, but from `0..(b-a)`... That caused a bug. See first commit for the fix.
2. Implement the `_: Trait` ambiguity hack. I put it in assemble, let me know if it should live elsewhere. This is important, since we otherwise consider `_: Sized` to have no solutions, and nothing passes!
3. Swap `Ambiguity` and `Unimplemented` cases for the new solver. Sorry for accidentally swapping them 😄
4. Check GATs' own predicates during projection confirmation.

Then implement a few builtin traits:

5. Implement `PointerSized`. Pretty independent.
6. Implement `Fn` family of traits for fnptr, fndef, and closures. Closures are currently broken because `FulfillCtxt::relationships` is intentionally left unimplemented. See comment in the test.

r? ```@lcnr```
2023-01-20 21:33:22 -05:00
bors
94a300b9b8 Auto merge of #105102 - compiler-errors:copy-impl-considering-regions, r=lcnr
Check ADT fields for copy implementations considering regions

Fixes #88901
r? `@ghost`
2023-01-20 21:29:52 +00:00
Michael Goulet
ed6aebbfec trait solver: Implement Fn traits and tuple trait 2023-01-19 16:15:28 +00:00
Michael Goulet
69890b2df4 trait solver: PointerSized 2023-01-19 16:15:28 +00:00
Esteban Küber
656db98bd9 Tweak E0597
CC #99430
2023-01-15 19:46:20 +00:00
Matthias Krüger
d7fcd01f67
Rollup merge of #106072 - eopb:dyn-derive, r=estebank
fix: misleading "add dyn keyword before derive macro" suggestion

Fixes #106071
2023-01-15 01:01:36 +01:00
Ethan Brierley
1caec6fa1d fix: misleading add dyn to derive macro suggestion 2023-01-14 12:14:06 +00:00
Matthias Krüger
8c538f7d83
Rollup merge of #106788 - estebank:elaborate_pred_E0599, r=compiler-errors
Tweak E0599 and elaborate_predicates

CC https://github.com/rust-lang/rust/issues/86377.
2023-01-14 13:04:26 +01:00
Matthias Krüger
108b5f462b
Rollup merge of #106752 - sulami:master, r=estebank
Emit a hint for bad call return types due to generic arguments

When the return type of a function call depends on the type of an argument, e.g.

```
fn foo<T>(x: T) -> T {
    x
}
```

and the expected type is set due to either an explicitly typed binding, or because the call to the function is in a tail position without semicolon, the current error implies that the argument in the call has the wrong type.

This new hint highlights that the expected type doesn't match the returned type, which matches the argument type, and that that's why we're flagging the argument type.

Fixes #43608.
2023-01-14 13:04:26 +01:00
kadmin
2de9d679ad Add note when FnPtr vs. FnDef impl trait
I encountered an instance where an `FnPtr` implemented a trait, but I was passing an `FnDef`. To
the end user, there is really no way to differentiate each of them, but it is necessary to cast
to the generic function in order to compile. It is thus useful to suggest `as` in the help note,
(even if the Fn output implements the trait).
2023-01-14 10:37:56 +00:00
Michael Goulet
75074e0e52 Delay normalization bugs instead of reporting them 2023-01-13 23:19:36 +00:00
Michael Goulet
6ec8c13e15 Rebase and move UI tests 2023-01-13 23:06:29 +00:00
Esteban Küber
81ba427a7b Add tests 2023-01-13 18:20:24 +00:00
Esteban Küber
3d6b09e53e Keep obligation chain when elaborating obligations 2023-01-13 18:20:23 +00:00
Matthias Krüger
c6e3a47843
Rollup merge of #106585 - estebank:issue-46585, r=compiler-errors
When suggesting writing a fully qualified path probe for appropriate types

Address the more common part of #46585.
2023-01-13 19:16:42 +01:00
Yuki Okushi
5adc7a5e37
Rollup merge of #106785 - compiler-errors:better-impl-wf-spans, r=estebank
Make blame spans better for impl wfcheck

r? types
2023-01-13 16:54:24 +09:00
Robin Schroer
a3cf3822d2
Emit a hint for bad call return types due to generic arguments
When the return type of a function call depends on the type of an
argument, e.g.

```
fn foo<T>(x: T) -> T {
    x
}
```

and the expected type is set due to either an explicitly typed
binding, or because the call to the function is in a tail position
without semicolon, the current error implies that the argument in the
call has the wrong type.

This new hint highlights that the expected type doesn't match the
returned type, which matches the argument type, and that that's why
we're flagging the argument type.

Fixes #43608.
2023-01-13 13:34:55 +09:00
Michael Goulet
5924c2511e Only point at impl self ty in WF if trait predicate shares self ty 2023-01-12 22:25:30 +00:00
Michael Goulet
950b47fb96 Render missing generics suggestion verbosely 2023-01-12 22:04:30 +00:00
Michael Goulet
2aabb0fd5d Point at impl self type for impl wf obligations 2023-01-12 20:44:47 +00:00
Michael Goulet
d76e168f01 Point at HIR types when impl trait ref doesn't normalize 2023-01-12 20:44:47 +00:00