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

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Wed Sep 7 11:08:23 PDT 2016


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/6cff05a5/attachment.html>


More information about the cfe-commits mailing list