Diagnostic proposal

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Diagnostic proposal

Hans Wennborg via cfe-dev
Hi @clang,

I have a small proposal for an improved error message. Consider

https://godbolt.org/z/j3i9jy

There the function foo for the template class is instantiated for int, because foo is virtual. A non-virtual function wouldn't get instantiated (since it is not used) and no error would be generated. Currently the diagnostic only hints to the constructor as the final instantiation context. An extended message, that the function is instantiated, because it is virtual, would be helpful.
Otherwise, with a larger c'tor and a more complex class hierarchy it is not so easy to tell, what is going on.

Best Olaf

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic proposal

Hans Wennborg via cfe-dev
On Tue, Jan 28, 2020 at 10:40 AM via cfe-dev <[hidden email]> wrote:
Hi @clang,

I have a small proposal for an improved error message. Consider

https://godbolt.org/z/j3i9jy

There the function foo for the template class is instantiated for int, because foo is virtual. A non-virtual function wouldn't get instantiated (since it is not used) and no error would be generated. Currently the diagnostic only hints to the constructor as the final instantiation context. An extended message, that the function is instantiated, because it is virtual, would be helpful.
Otherwise, with a larger c'tor and a more complex class hierarchy it is not so easy to tell, what is going on.

I don't think that posting "proposed new error message" ideas to cfe-dev@ is likely to be useful, unless you are posting to say that you are working on a patch.

If anyone does work on a patch to improve Clang's notes on why a template function is being instantiated: I offer this other example, which came up on the Cpplang Slack workspace last week.
The destructor of Indestructible<true> is instantiated because it's needed by A<Indestructible<true>>'s implicitly defaulted destructor. The compiler error message doesn't indicate this relationship.  I believe the root cause is the same as Olaf's case.  A patch that improves the handling of one should improve the other as well, I would hope.

–Arthur


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev