[llvm-bugs] [Bug 47928] New: "Did you mean" suggests deprecated namespaces before non-deprecated ones

[via llvm-bugs]

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: unassignedclangbugs at nondot.org
          Reporter: arthur.j.odwyer at gmail.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201021/fc3f9c39/attachment.html>