Re: [cfe-users] dynmaic_cast in uninstantiated function templates

2018-11-05 Thread via cfe-users 
Thanks for the clarification. So a solution could be a template make_dependent

template
struct make_dependent
{
  typedef X type;
};

template
void fn(A* a, T& x)
{
  dynamic_cast::type>(a);
}

The standard doesn't supply any similar, does it?

Best Olaf



-Ursprüngliche Nachricht-
Von: Mat Sutcliffe [mailto:oktal3...@gmail.com] 
Gesendet: Mittwoch, 24. Oktober 2018 18:42
An: Krzikalla, Olaf; cfe-users@lists.llvm.org
Betreff: Re: [cfe-users] dynmaic_cast in uninstantiated function templates

On Wed, 24 Oct 2018 at 02:06, Olaf wrote:
>
> the code below compiles on gcc and icc, but not on clang with the error:
>
> source_file.cpp:14:16: error: 'B' is an incomplete type
>   if (auto b = dynamic_cast(a))
>
> However fn is an uninstantiated function template.
> Is this a glitch in clang or is clang the only one right here?
>
> class B;
>
> template
> void fn(A* a, T& x)
> {
>   dynamic_cast(a);
> }

All three compilers are correct here, as far as the standard is
concerned. The code is ill-formed, but implementations are not
required to diagnose this kind of error. There is no type T that could
produce a well-formed instantiation of fn.
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] problem with `candidate template ignored: invalid explicitly-specified argument'

2018-11-05 Thread David Blaikie via cfe-users 
Yeah, looks like a bug in Clang to me - CC'ing Richard Smith in case this
is quick/easy/obvious to him. Here's my slightly modified test case
comparing Clang and GCC's behavior, and adding a non-member overload
situation to demonstrate that that works on both compilers:
https://godbolt.org/z/cTq06R

On Sat, Nov 3, 2018 at 3:19 PM Werner LEMBERG via cfe-users <
cfe-users@lists.llvm.org> wrote:

>
> Folks,
>
>
> below is a MWE that compiles fine with g++ but fails with clang
> (tested version 6.0.1 on a GNU/Linux box):
>
>   clang-problem.cpp:19:7: error:
>   no matching member function for call to 'zip'
> bex.zip <&B::fun> ();
> ^
>   clang-problem.cpp:13:8: note: candidate template ignored:
>   invalid explicitly-specified argument for template parameter 'mf'
> void zip () { }
>  ^
>
> To my best knowledge, the code is valid C++.  This means there are two
> possible corrolaries: either I'm wrong, and it is not valid C++
> according to the standard, or clang++ has a bug.  Hopefully, it's the
> former.
>
> Can you point out a solution?
>
>
> Werner
>
>
> ==
>
>
> class A {
> public:
>   template 
>   void zip () { }
>   void fun () { }
> };
>
> class B : public A
> {
> public:
>   using A::zip; // Fails to involve A::zip in overloading resolution
>   template 
>   void zip () { }
> } bex;
>
>
> void x ()
> {
>   bex.zip <&B::fun> ();
> }
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] problem with `candidate template ignored: invalid explicitly-specified argument'

2018-11-05 Thread Jan Korous via cfe-users 
I minimized the reproducer. Seems like base class template methods are not 
included in derived object method name resolution.

Knowing whether it violates the standard or not is beyond my knowledge though.

type params
https://godbolt.org/z/WpET78

nontype params
https://godbolt.org/z/PZIaDn

Jan

> On Nov 5, 2018, at 4:36 PM, David Blaikie via cfe-users 
>  wrote:
> 
> Yeah, looks like a bug in Clang to me - CC'ing Richard Smith in case this is 
> quick/easy/obvious to him. Here's my slightly modified test case comparing 
> Clang and GCC's behavior, and adding a non-member overload situation to 
> demonstrate that that works on both compilers: https://godbolt.org/z/cTq06R 
>  
> 
> On Sat, Nov 3, 2018 at 3:19 PM Werner LEMBERG via cfe-users 
> mailto:cfe-users@lists.llvm.org>> wrote:
> 
> Folks,
> 
> 
> below is a MWE that compiles fine with g++ but fails with clang
> (tested version 6.0.1 on a GNU/Linux box):
> 
>   clang-problem.cpp:19:7: error:
>   no matching member function for call to 'zip'
> bex.zip <&B::fun> ();
> ^
>   clang-problem.cpp:13:8: note: candidate template ignored:
>   invalid explicitly-specified argument for template parameter 'mf'
> void zip () { }
>  ^
> 
> To my best knowledge, the code is valid C++.  This means there are two
> possible corrolaries: either I'm wrong, and it is not valid C++
> according to the standard, or clang++ has a bug.  Hopefully, it's the
> former.
> 
> Can you point out a solution?
> 
> 
> Werner
> 
> 
> ==
> 
> 
> class A {
> public:
>   template 
>   void zip () { }
>   void fun () { }
> };
> 
> class B : public A
> {
> public:
>   using A::zip; // Fails to involve A::zip in overloading resolution
>   template 
>   void zip () { }
> } bex;
> 
> 
> void x ()
> {
>   bex.zip <&B::fun> ();
> }
> 
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users 
> 
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] [clang-format] Trailing return type

2018-11-05 Thread Mateusz Loskot via cfe-users 
On Fri, 2 Nov 2018 at 06:11, Owen Pan  wrote:
>
> I think that was a bug fix as the latest clang-format will convert the 
> "Before" code to "After" even in the absence of the .clang-format 
> configuration file.

Thanks for the hint.
I upgraded from 6.0 to 7.0 and it does handle the trailing return types indeed.

I noticed one issue which I wonder if it does qualify for a bug report:

TL;TR: arrow followed by typename keyword is not handled

Before:

template 
auto bbb(detail::base& p) -> typename
std::add_lvalue_reference::type;

After:

template 
auto bbb(detail::base &p) ->
typename std::add_lvalue_reference::type;

Whereas, if typename is removed:

Before

template 
auto ccc(detail::base& p) ->
std::add_lvalue_reference::type;

After:

template 
auto ccc(detail::base &p)
-> std::add_lvalue_reference::type;

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] problem with `candidate template ignored: invalid explicitly-specified argument'

2018-11-05 Thread David Blaikie via cfe-users 
Ah, good point - I didn't think to simplify the template argument
list/types too!

On Mon, Nov 5, 2018 at 10:18 AM Jan Korous  wrote:

> I minimized the reproducer. Seems like base class template methods are not
> included in derived object method name resolution.
>
> Knowing whether it violates the standard or not is beyond my knowledge
> though.
>
> type params
> https://godbolt.org/z/WpET78
>
> nontype params
> https://godbolt.org/z/PZIaDn
>
> Jan
>
>
> On Nov 5, 2018, at 4:36 PM, David Blaikie via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
> Yeah, looks like a bug in Clang to me - CC'ing Richard Smith in case this
> is quick/easy/obvious to him. Here's my slightly modified test case
> comparing Clang and GCC's behavior, and adding a non-member overload
> situation to demonstrate that that works on both compilers:
> https://godbolt.org/z/cTq06R
>
> On Sat, Nov 3, 2018 at 3:19 PM Werner LEMBERG via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
>>
>> Folks,
>>
>>
>> below is a MWE that compiles fine with g++ but fails with clang
>> (tested version 6.0.1 on a GNU/Linux box):
>>
>>   clang-problem.cpp:19:7: error:
>>   no matching member function for call to 'zip'
>> bex.zip <&B::fun> ();
>> ^
>>   clang-problem.cpp:13:8: note: candidate template ignored:
>>   invalid explicitly-specified argument for template parameter 'mf'
>> void zip () { }
>>  ^
>>
>> To my best knowledge, the code is valid C++.  This means there are two
>> possible corrolaries: either I'm wrong, and it is not valid C++
>> according to the standard, or clang++ has a bug.  Hopefully, it's the
>> former.
>>
>> Can you point out a solution?
>>
>>
>> Werner
>>
>>
>> ==
>>
>>
>> class A {
>> public:
>>   template 
>>   void zip () { }
>>   void fun () { }
>> };
>>
>> class B : public A
>> {
>> public:
>>   using A::zip; // Fails to involve A::zip in overloading resolution
>>   template 
>>   void zip () { }
>> } bex;
>>
>>
>> void x ()
>> {
>>   bex.zip <&B::fun> ();
>> }
>>
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users