From ac17daf96bf3a5f6ed663328c262cf676a689c44 Mon Sep 17 00:00:00 2001 From: Matthew Woodcraft Date: Sun, 6 Feb 2022 13:51:52 +0000 Subject: [PATCH 1/4] method lookup: fix miscapitalised function name --- src/method-lookup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index 250eea034..ee9ce3bf1 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -89,7 +89,7 @@ method. So, let's continue our example. Imagine that we were calling a method `foo` with the receiver `Rc>` and there is a trait `Foo` that defines it with `&self` for the type `Rc` as well as a method -on the type `Box` that defines `Foo` but with `&mut self`. Then we +on the type `Box` that defines `foo` but with `&mut self`. Then we might have two candidates: - `&Rc>` from the impl of `Foo` for `Rc` where `U=Box<[T; 3]>` From cb8a7ad5e707058ae81ab86751c2611f6f685fee Mon Sep 17 00:00:00 2001 From: Matthew Woodcraft Date: Sun, 6 Feb 2022 14:32:08 +0000 Subject: [PATCH 2/4] method lookup: say that inherent candidates take priority --- src/method-lookup.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index ee9ce3bf1..54b57917a 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -100,8 +100,9 @@ might have two candidates: Finally, to actually pick the method, we will search down the steps, trying to match the receiver type against the candidate types. At each step, we also consider an auto-ref and auto-mut-ref to see whether -that makes any of the candidates match. We pick the first step where -we find a match. +that makes any of the candidates match. For each resulting receiver +type, we consider inherent candidates before extension candidates. +We pick the first match we find. In the case of our example, the first step is `Rc>`, which does not itself match any candidate. But when we autoref it, we From 77e5068c7e7ebaf0a97272c30f0f3e0cbd901f51 Mon Sep 17 00:00:00 2001 From: Matthew Woodcraft Date: Sun, 6 Feb 2022 14:54:45 +0000 Subject: [PATCH 3/4] method lookup: fix description of assembling extension candidates Say that the list of extension candidates is made without looking at the receiver type. --- src/method-lookup.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index 54b57917a..e52ce1b24 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -79,12 +79,10 @@ behavior should be reconsidered in light of where clauses. TODO: Is this FIXME still accurate? **Extension candidates** are derived from imported traits. If I have -the trait `ToString` imported, and I call `to_string()` on a value of -type `T`, then we will go off to find out whether there is an impl of -`ToString` for `T`. These kinds of method calls are called "extension -methods". They can be defined in any crate, not only the one that -defined `T`. Furthermore, you must import the trait to call such a -method. +the trait `ToString` imported, and I call `to_string()` as a method, +then we will list the `to_string()` definition in each impl of +`ToString` as a candidate. These kinds of method calls are called +"extension methods". So, let's continue our example. Imagine that we were calling a method `foo` with the receiver `Rc>` and there is a trait `Foo` @@ -92,8 +90,8 @@ that defines it with `&self` for the type `Rc` as well as a method on the type `Box` that defines `foo` but with `&mut self`. Then we might have two candidates: -- `&Rc>` from the impl of `Foo` for `Rc` where `U=Box<[T; 3]>` -- `&mut Box<[T; 3]>>` from the inherent impl on `Box` where `U=[T; 3]` +- `&Rc` as an extension candidate +- `&mut Box` as an inherent candidate ### Candidate search @@ -106,7 +104,7 @@ We pick the first match we find. In the case of our example, the first step is `Rc>`, which does not itself match any candidate. But when we autoref it, we -get the type `&Rc>` which does match. We would then +get the type `&Rc>` which matches `&Rc`. We would then recursively consider all where-clauses that appear on the impl: if those match (or we cannot rule out that they do), then this is the method we would pick. Otherwise, we would continue down the series of From 887ec75446697eef109da2cb44ae841b35d89854 Mon Sep 17 00:00:00 2001 From: Matthew Woodcraft Date: Sun, 6 Feb 2022 15:05:04 +0000 Subject: [PATCH 4/4] method lookup: describe ambiguity handling --- src/method-lookup.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index e52ce1b24..8eb8ec5ce 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -100,7 +100,9 @@ trying to match the receiver type against the candidate types. At each step, we also consider an auto-ref and auto-mut-ref to see whether that makes any of the candidates match. For each resulting receiver type, we consider inherent candidates before extension candidates. -We pick the first match we find. +If there are multiple matching candidates in a group, we report an +error, except that multiple impls of the same trait are treated as a +single match. Otherwise we pick the first match we find. In the case of our example, the first step is `Rc>`, which does not itself match any candidate. But when we autoref it, we