usaxena95 marked 4 inline comments as done.
usaxena95 added a comment.
I have switched to a version where we matched template heads only when they are
constraints. This is for the moment to unblock the existing bugs and not break
existing code prior to C++20.
Let us continue the discussion over the possibility of introducing an ambiguity
in https://github.com/llvm/llvm-project/issues/58571
================
Comment at: clang/lib/Sema/SemaOverload.cpp:1307
+ // C++ [namespace.udecl]p4:
+ // The member from the base class is hidden or overridden by the
+ // implicitly-declared copy/move constructor or assignment operator of
the
----------------
ilya-biryukov wrote:
> How is this related to checking whether the template parameter lists check?
> I seems to be missing the logical connection that goes from the standard
> wording to the code. Could you explain?
>
> An example that I have in mind is:
> ```
> struct A {
> template <class T, class U = int> A(T);
> template <class T, class U = int> int foo(T);
> };
> struct B : A {
> using A::A;
> template <class T> B(T);
>
> using A::foo;
> template <class T> int foo(T);
> };
>
> namespace detail {
> template <class T> int bar(T);
> }
> using detail::bar;
> template <class T, class U = int> int bar(T);
>
> int a = bar(10); // this is definitely ambiguous.
>
> B b(10); // should this be ambiguous?
> int c = b.foo(10); // should this be ambiguous?
> // Should constructors and functions behave differently? Why?
> ```
>
> I [see](https://gcc.godbolt.org/z/z4Ko1ehPe) that both Clang and GCC treat
> member declarations differently, but I don't see why they should given that
> they are supposed to use the same "corresponds" terminology from the
> standard. What am I missing?
I have filed https://github.com/llvm/llvm-project/issues/58571 to discuss the
interpretation of the standard.
================
Comment at: clang/test/SemaTemplate/concepts-using-decl.cpp:110
+ expect<1>(bar2{}.foo<Empty>());
+ // FIXME: Candidates from using-decls should be dropped in case of ambiguity.
+ expect<1>(baz{}.foo<Empty>()); // expected-error {{call to member function
'foo' is ambiguous}}
----------------
ilya-biryukov wrote:
> Why should they be dropped? Could you provide pointers from the standard?
I think I misunderstood that using decls should not be introducing ambiguities.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D136440/new/
https://reviews.llvm.org/D136440
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
