On Tue, Sep 6, 2016 at 10:55 PM, George Burgess IV <
george.burgess...@gmail.com> wrote:
> george.burgess.iv added a comment.
>
> > Although I think that users will expect atomic_add(unsigned int *, 5) to
> work.without error
>
>
> Totally agree; I was just making sure that I understood the problem. :)
>
> I think, with a small tweak in semantics, we can make everything work
> without needing to patch existing code. Let me play around a little.
It seems to me that we could handle this by ranking viable-but-ill-formed
conversion sequences before non-viable ones in
clang::isBetterOverloadCandidate. This problem is actually more general
than __attribute__((overloadable)) in C -- there is one form of ill-formed
implicit conversion sequence that we accept in C++ that leads to the same
problem:
void f(char*, int);
void f(const char*, unsigned);
void g() { f("foo", 0); }
Clang reports an ambiguity on line 3, but in C++11 onwards this code is
valid because there is no implicit conversion sequence from a string
literal to char*. (We provide one as an extension, and it's ranked worse
than any other conversion.)
> Repository:
> rL LLVM
>
> https://reviews.llvm.org/D24113
>
>
>
>
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
