https://bugs.llvm.org/show_bug.cgi?id=47928
Bug ID: 47928
Summary: "Did you mean" suggests deprecated namespaces before
non-deprecated ones
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
// https://godbolt.org/z/YT1Tra
namespace Views {
int Take();
}
namespace [[deprecated("use Views instead")]] View {
using Views::Take;
}
int main() {
int x = ::Take();
}
<source>:10:13: error: no member named 'Take' in the global namespace; did you
mean 'View::Take'?
int x = ::Take();
^~~~~~
View::Take
<source>:6:18: note: 'View::Take' declared here
using Views::Take;
^
This is reduced from a real piece of code using Range-v3
ranges::view{,s}::take. It seems completely backwards that Clang would suggest
the deprecated synonym (from the using-declaration) rather than the true
version from the non-deprecated namespace.
Perhaps Clang is just thinking that the edit distance between "" and "views" is
longer than the edit distance between "" and "view". However, I think it would
be a nice UX improvement to also consider what kind of entity is being
suggested (is it just a synonym for something from a different namespace? then
follow the symlink) and whether the suggested entity has been explicitly
deprecated (then maybe don't consider it a candidate for suggestion at all).
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
