-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need check for multiple applicable items in scope #355
Labels
Projects
Milestone
Comments
philberty
added a commit
that referenced
this issue
Apr 10, 2021
In order to support name resolution and checks for duplicate definitions of names we need canonical paths for all DefId items such as inherent impl items and normal items. Consider: struct Foo<T>(T); impl Foo<f32> { fn name()... } impl Foo<i32> { fn name()... } Each of the impl blocks have a name function but these are seperate due to the concrete impl of the Parameter type passed in. The caveat here is that to call this Function name the programmer must be explicit in which implentation they wish to call such as: let a = Foo::<f32>::name(); This lets the Path probe lookup the apropriate impl block. The problem here is that rust also allows for the compiler to infer the impl you wish such as: let a = Foo::name(); This should fail since there are multiple candidates possible for this Path. Unless there might have only been one name function in which case it would have worked. This does not support looking for any inherent impl items overlapping such as: rustc_typeck/src/coherence/inherent_impls_overlap.rs - see #353 Fixes #355 #335
philberty
added a commit
that referenced
this issue
Apr 12, 2021
In order to support name resolution and checks for duplicate definitions of names we need canonical paths for all DefId items such as inherent impl items and normal items. Consider: struct Foo<T>(T); impl Foo<f32> { fn name()... } impl Foo<i32> { fn name()... } Each of the impl blocks have a name function but these are seperate due to the concrete impl of the Parameter type passed in. The caveat here is that to call this Function name the programmer must be explicit in which implentation they wish to call such as: let a = Foo::<f32>::name(); This lets the Path probe lookup the apropriate impl block. The problem here is that rust also allows for the compiler to infer the impl you wish such as: let a = Foo::name(); This should fail since there are multiple candidates possible for this Path. Unless there might have only been one name function in which case it would have worked. This does not support looking for any inherent impl items overlapping such as: rustc_typeck/src/coherence/inherent_impls_overlap.rs - see #353 Fixes #355 #335 #325
bors bot
added a commit
that referenced
this issue
Apr 12, 2021
358: Canonical Paths for Name Resolution and handle TurboFish properly r=philberty a=philberty Add Canonical paths to name resolution In order to support name resolution and checks for duplicate definitions of names we need canonical paths for all DefId items such as inherent impl items and normal items. Consider: ```rust struct Foo<T>(T); impl Foo<f32> { fn name()... } impl Foo<i32> { fn name()... } ``` Each of the impl blocks have a name function but these are separate due to the concrete impl of the Parameter type passed in. The caveat here is that to call this Function name the programmer must be explicit in which implentation they wish to call such as: ```rust let a = Foo::<f32>::name(); ``` This lets the Path probe lookup the appropriate impl block. The problem here is that rust also allows for the compiler to infer the impl you wish such as: ```rust let a = Foo::name(); ``` This should fail since there are multiple candidates possible for this Path. Unless there might have only been one name function in which case it would have worked. This patch is also responsible to implement PathInExpression by iterating each segment and applying generic arguments as we go. Fixes #355 #335 #325 #353 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
bors bot
added a commit
that referenced
this issue
Apr 13, 2021
358: Canonical Paths for Name Resolution and handle TurboFish properly r=philberty a=philberty Add Canonical paths to name resolution In order to support name resolution and checks for duplicate definitions of names we need canonical paths for all DefId items such as inherent impl items and normal items. Consider: ```rust struct Foo<T>(T); impl Foo<f32> { fn name()... } impl Foo<i32> { fn name()... } ``` Each of the impl blocks have a name function but these are separate due to the concrete impl of the Parameter type passed in. The caveat here is that to call this Function name the programmer must be explicit in which implentation they wish to call such as: ```rust let a = Foo::<f32>::name(); ``` This lets the Path probe lookup the appropriate impl block. The problem here is that rust also allows for the compiler to infer the impl you wish such as: ```rust let a = Foo::name(); ``` This should fail since there are multiple candidates possible for this Path. Unless there might have only been one name function in which case it would have worked. This patch is also responsible to implement PathInExpression by iterating each segment and applying generic arguments as we go. Fixes #355 #335 #325 #353 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This error only occurs when the compiler needs to resolve the PathExpr because it can resolve to multiple items.
The text was updated successfully, but these errors were encountered: