Repository navigation
incorrect unstable_name_collision warning for unstable inherent method name #50232
Copy link
Copy link
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsArea: Documentation for any part of the project, including the compiler, standard library, and toolsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Activity
- addedC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]
on Apr 26, 2018 - addedT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.A-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsArea: Documentation for any part of the project, including the compiler, standard library, and toolsand removedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]
on Apr 26, 2018 What about this?
warning: once this method is added to the standard library, there will be ambiguity here, which will cause a hard error or change of behavior!
It seems the message is too long though.
Or simply:
warning: once this method is added to the standard library, the ambiguity may cause an error or change in behaviour!
(which is even shorter than the original.)
Reacted by kennytm and Trevor SpiteriIf the trait method parameters are different from the inherent method parameters, it could end up leading to a hard error for a different reason. For example for the code below, opening the feature gate will cause a hard error, but because of a type mismatch rather than because of ambiguity.
//#![feature(euclidean_division)] trait DivEuc { fn div_euc(self, rhs: u8) -> Self; } impl DivEuc for u32 { fn div_euc(self, rhs: u8) -> Self { self / rhs as u32 } } fn main() { println!("{}", 12u32.div_euc(3u8)); }
So a more generic error like @varkor suggests is better.
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsArea: Documentation for any part of the project, including the compiler, standard library, and toolsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Compiling the code below with nightly produces an unstable_name_collision warning. However the code works after enabling the feature gate, I presume because the unstable method is inherent and takes precedence over trait methods. In this particular case, it can still be worth warning that the behaviour of the standard library method can be different, but the current “warning: once this method is added to the standard library, there will be ambiguity here, which will cause a hard error!” is incorrect.