Fix hidden member templates in derived classes

Fix hidden member templates in derived classes

According to Clang's interpretation of the C++ standard, "member
functions in the derived class override and/or hide member functions
with the same name and parameter types in a base class". This seems
to also hold for templated member functions and even if the code has
a using-declaration of the base class member.
This affects LilyPond's implementation of the method_finder template.
Luckily, the problem can be solved by just re-declaring the base
template specializations in each derived class instead of 'using' them.
The only drawback is that this doesn't work out-of-the-box for deeper
inheritance hierarchies. However, this only affects three ligature
engravers so I think it's worth the maintenance to just encode the
transitive inheritance manually.

[lemzwerg, 2019-11-14 08:45:44]

Wait, this tiny patch makes lilypond compilable with clang, passing the whole
test suite?

[hahnjo, 2019-11-14 08:49:43]

On 2019/11/14 08:45:44, lemzwerg wrote:
> Wait, this tiny patch makes lilypond compilable with clang, passing the whole
> test suite?

You're quite fast with looking at patches, I wasn't even finished with pointing
you to this one :D
And yes, this works for me, at least on Linux (didn't test FreeBSD yet and don't
own a Mac). Plus it passes a full check with a test-baseline generated by GCC,
so I'm pretty confident it's also working correctly.

[lemzwerg, 2019-11-14 09:11:35]

> And yes, this works for me, at least on Linux (didn't test FreeBSD yet and
don't
> own a Mac). Plus it passes a full check with a test-baseline generated by GCC,
> so I'm pretty confident it's also working correctly.

Ho humm :-)  David K?

[dak, 2019-11-14 11:29:25]

On 2019/11/14 09:11:35, lemzwerg wrote:
> > And yes, this works for me, at least on Linux (didn't test FreeBSD yet and
> don't
> > own a Mac). Plus it passes a full check with a test-baseline generated by
GCC,
> > so I'm pretty confident it's also working correctly.
> 
> Ho humm :-)  David K?

This is an embarrassingly small change, yes.  After recent standard changes,
this year-long problem would eventually have become an issue.  I haven't yet
digged into the standards for another reading, but if both GCC and Clang agree
for now that this is fine, I'll not argue against it.  After all, the previous
version did become problematic after some C++14(?) change in the standards.

I am not a fan of having to keep the whole inheritance hierarchy in sight
(that's a loss of abstraction) but considering the actual impact this causes, it
seems like a small price to pay for getting rid of this headache.

[lemzwerg, 2019-11-14 11:59:34]

Great!  Jonas, please add comments to the source code that points to the
relevant gcc vs. clang discussion.

[Dan Eble, 2019-11-14 13:32:47]

https://codereview.appspot.com/559250043/diff/547250043/lily/include/translat...
File lily/include/translator.hh (right):

https://codereview.appspot.com/559250043/diff/547250043/lily/include/translat...
lily/include/translator.hh:204: // Fallback for non-overriden callbacks for
which &T::x degrades to
Should this comment be moved with the function?

[hahnjo, 2019-11-14 16:26:42]

On 2019/11/14 11:29:25, dak wrote:
> [...]
> I am not a fan of having to keep the whole inheritance hierarchy in sight
> (that's a loss of abstraction) but considering the actual impact this causes,
it
> seems like a small price to pay for getting rid of this headache.

The other option (that I just tested) is to move the method_finder
implementation out of the classes, ie make them a static function in the global
namespace. This requires a quite mechanical change for all classes to call
DECLARE_TRANSLATOR_CALLBACKS (<<<class>>>) right after their declaration and
making Translator::trampoline public (136 files changed, 279 insertions(+), 18
deletions(-)). To be honest, I like this less than this patch, but it does avoid
the lost abstraction in the three ligature engravers.

On 2019/11/14 11:59:34, lemzwerg wrote:
> Great!  Jonas, please add comments to the source code that points to the
> relevant gcc vs. clang discussion.

Where exactly would you put such comment? IMO we don't need to justify writing
correct code (or at least code that both compilers accept eventually).

[lemzwerg, 2019-11-14 17:28:23]

> > Great!  Jonas, please add comments to the source code
> >that points to the relevant gcc vs. clang discussion.
> 
> Where exactly would you put such comment?  IMO we don't
> need to justify writing correct code (or at least code
> that both compilers accept eventually).

Fair point, so please forget my suggestion.

[hahnjo, 2019-11-18 17:42:35]

Move comment that I overlooked