[PATCH] D24113: Allow implicit conversions between incompatible pointer types in overload resolution in C.

[George Burgess IV via cfe-commits]

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 <richard at metafoo.co.uk>
wrote:

> On Tue, Sep 6, 2016 at 10:55 PM, George Burgess IV <
> george.burgess.iv at 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
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160907/28439649/attachment.html>