Fix committed as r280847 -- thanks for the reports!
> It seems to me that we could handle this by ranking viable-but-ill-formed
conversion sequences before non-viable ones in
clang::isBetterOverloadCandidate
That's what I was thinking, too. :)
> Clang reports an ambiguity on line 3
TIL. Woohoo for extensions! r280847 should fix this, as well.
On Wed, Sep 7, 2016 at 11:08 AM, Richard Smith <rich...@metafoo.co.uk>
wrote:
> 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
