compilation with clang

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

compilation with clang

Werner LEMBERG

[git 964722f8046cbc77633fb8efbc4696677a579311]


Folks,


for better support of lilypond on MacOS I think it would be a good
idea to be able to compile lilypond with clang.  Trying so with
clang-6.0 as provided by my openSuSE GNU/Linux box quickly aborts as
follows (clang-6.0 on my MacOS Lion box fails in the same way, BTW).

======================================================================

volta-engraver.cc:200:1: error:
    no matching function for call to 'method_finder'
ADD_TRANSLATOR (Volta_engraver,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/translator.icc:67:3: note:
    expanded from macro 'ADD_TRANSLATOR'
  IMPLEMENT_FETCH_PRECOMPUTABLE_METHODS (classname);                    \
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/translator.icc:78:7: note:
    expanded from macro 'IMPLEMENT_FETCH_PRECOMPUTABLE_METHODS'
      method_finder <&T::start_translation_timestep> ();                \
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
volta-engraver.cc:43:3: note: candidate template ignored:
    invalid explicitly-specified argument for template parameter 'mf'
  TRANSLATOR_DECLARATIONS (Volta_engraver);
  ^
./include/translator.hh:111:3: note:
    expanded from macro 'TRANSLATOR_DECLARATIONS'
  TRANSLATOR_FAMILY_DECLARATIONS (NAME);                                \
  ^
./include/translator.hh:78:3: note:
    expanded from macro 'TRANSLATOR_FAMILY_DECLARATIONS'
  DECLARE_TRANSLATOR_CALLBACKS (NAME);                                  \
  ^
./include/translator.hh:87:14: note:
    expanded from macro 'DECLARE_TRANSLATOR_CALLBACKS'
  static SCM method_finder ()                                           \
             ^
volta-engraver.cc:43:3: note: candidate template ignored:
    invalid explicitly-specified argument for template parameter 'mf'
./include/translator.hh:111:3: note:
    expanded from macro 'TRANSLATOR_DECLARATIONS'
  TRANSLATOR_FAMILY_DECLARATIONS (NAME);                                \
  ^
./include/translator.hh:78:3: note:
    expanded from macro 'TRANSLATOR_FAMILY_DECLARATIONS'
  DECLARE_TRANSLATOR_CALLBACKS (NAME);                                  \
  ^
./include/translator.hh:92:14: note:
    expanded from macro 'DECLARE_TRANSLATOR_CALLBACKS'
  static SCM method_finder ()                                           \
             ^
volta-engraver.cc:43:3: note: candidate template ignored:
    invalid explicitly-specified argument for template parameter 'mf'
./include/translator.hh:111:3: note:
    expanded from macro 'TRANSLATOR_DECLARATIONS'
  TRANSLATOR_FAMILY_DECLARATIONS (NAME);                                \
  ^
./include/translator.hh:78:3: note:
    expanded from macro 'TRANSLATOR_FAMILY_DECLARATIONS'
  DECLARE_TRANSLATOR_CALLBACKS (NAME);                                  \
  ^
./include/translator.hh:97:14: note:
    expanded from macro 'DECLARE_TRANSLATOR_CALLBACKS'
  static SCM method_finder () {                                         \
             ^
======================================================================

Looking around in the internet it seems that this is a real problem,
violating the C++11 standard, cf.

  https://stackoverflow.com/questions/33872039/invalid-explicitly-specified-argument-in-clang-but-successful-compilation-in-gcc

Unfortunately, I'm completely stuck with a fix – my C++ knowledge is
simply too limited.  Anyone here who could help?


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

David Kastrup
Werner LEMBERG <[hidden email]> writes:

> ./include/translator.hh:78:3: note:
>     expanded from macro 'TRANSLATOR_FAMILY_DECLARATIONS'
>   DECLARE_TRANSLATOR_CALLBACKS (NAME);                                  \
>   ^
> ./include/translator.hh:97:14: note:
>     expanded from macro 'DECLARE_TRANSLATOR_CALLBACKS'
>   static SCM method_finder () {                                         \
>              ^
> ======================================================================
>
> Looking around in the internet it seems that this is a real problem,
> violating the C++11 standard, cf.
>
>   https://stackoverflow.com/questions/33872039/invalid-explicitly-specified-argument-in-clang-but-successful-compilation-in-gcc
>
> Unfortunately, I'm completely stuck with a fix – my C++ knowledge is
> simply too limited.  Anyone here who could help?

I thought that they had fixed this.  Rewriting this in a manner not
relying on the C++11 (and earlier IIRC) resolution rules is not all that
feasible: this is really heavily making use of it.  You'd have to do the
whole method finding business in a completely different manner.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG
>> Looking around in the internet it seems that this is a real
>> problem, violating the C++11 standard, cf.
>>
>>   https://stackoverflow.com/questions/33872039/invalid-explicitly-specified-argument-in-clang-but-successful-compilation-in-gcc
>>
>> Unfortunately, I'm completely stuck with a fix – my C++ knowledge
>> is simply too limited.  Anyone here who could help?
>
> I thought that they had fixed this.

Well, the comments in the above link say that the stackexchange
example is buggy and that there isn't a bug in clang, cf.

  https://bugs.llvm.org/show_bug.cgi?id=25693

> Rewriting this in a manner not relying on the C++11 (and earlier
> IIRC) resolution rules is not all that feasible: this is really
> heavily making use of it.  You'd have to do the whole method finding
> business in a completely different manner.

Are you *sure* that lilypond's code conforms to C++11?  Could you
extract a MWE so that I can create a question on stackexchange?


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

David Kastrup
Werner LEMBERG <[hidden email]> writes:

>>> Looking around in the internet it seems that this is a real
>>> problem, violating the C++11 standard, cf.
>>>
>>>   https://stackoverflow.com/questions/33872039/invalid-explicitly-specified-argument-in-clang-but-successful-compilation-in-gcc
>>>
>>> Unfortunately, I'm completely stuck with a fix – my C++ knowledge
>>> is simply too limited.  Anyone here who could help?
>>
>> I thought that they had fixed this.
>
> Well, the comments in the above link say that the stackexchange
> example is buggy and that there isn't a bug in clang, cf.
>
>   https://bugs.llvm.org/show_bug.cgi?id=25693
>
>> Rewriting this in a manner not relying on the C++11 (and earlier
>> IIRC) resolution rules is not all that feasible: this is really
>> heavily making use of it.  You'd have to do the whole method finding
>> business in a completely different manner.
>
> Are you *sure* that lilypond's code conforms to C++11?

I had read the standard on this after the first report.  It was pretty
clear I thought.  We had a discussion then.  I think that Mojca reported
it then, maybe you can look this up.

> Could you extract a MWE so that I can create a question on
> stackexchange?

What would that be good for?

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG

>> Are you *sure* that lilypond's code conforms to C++11?
>
> I had read the standard on this after the first report.  It was
> pretty clear I thought.  We had a discussion then.  I think that
> Mojca reported it then, maybe you can look this up.

Found it, together with your MWE.  Note that there wasn't a reply on
the macports-dev list...

>> Could you extract a MWE so that I can create a question on
>> stackexchange?
>
> What would that be good for?

The idea is that other people can have a look at it, too.  Maybe this
helps.

  http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html


    Werner

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG

>>> Could you extract a MWE so that I can create a question on
>>> stackexchange?
>>
>> What would that be good for?
>
> The idea is that other people can have a look at it, too.

And answers are trickling in; see thread starting with

  http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html


    Werner

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

David Kastrup
Werner LEMBERG <[hidden email]> writes:

>>>> Could you extract a MWE so that I can create a question on
>>>> stackexchange?
>>>
>>> What would that be good for?
>>
>> The idea is that other people can have a look at it, too.
>
> And answers are trickling in; see thread starting with
>
>   http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html

That's not exactly what I call "Stackexchange" though.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG

>>>> What would that be good for?
>>>
>>> The idea is that other people can have a look at it, too.
>>
>> And answers are trickling in; see thread starting with
>>
>>   http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html
>
> That's not exactly what I call "Stackexchange" though.

Indeed.  After some thinking I decided that the list is a better forum
for asking such a question – it's hard to justify a new question on
StackExchange with exactly the same title as another question, even if
the problem is slightly different.


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG
In reply to this post by Werner LEMBERG
> And answers are trickling in; see thread starting with
>
>   http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html

Is the work-around shown in

  https://godbolt.org/z/cTq06R

usable for lilypond?


    Werner

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

David Kastrup
Werner LEMBERG <[hidden email]> writes:

>> And answers are trickling in; see thread starting with
>>
>>   http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html
>
> Is the work-around shown in
>
>   https://godbolt.org/z/cTq06R
>
> usable for lilypond?

No.  It's not C++08 syntax, and LilyPond actually makes use of the
overloading resolution (which of the templates is called depends on
where in the hierarchy the function that the function pointer refers to
is defined) as part of the macro framework used here and thus it's not
possible to manually resolve the override and kill all the prospective
alternatives.

If the Clang developers refuse to fix the bug, we'll just stick with the
current scheme: we don't need Clang to compile the MacOSX version of
LilyPond.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

David Kastrup
David Kastrup <[hidden email]> writes:

> Werner LEMBERG <[hidden email]> writes:
>
>>> And answers are trickling in; see thread starting with
>>>
>>>   http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html
>>
>> Is the work-around shown in
>>
>>   https://godbolt.org/z/cTq06R
>>
>> usable for lilypond?
>
> No.  It's not C++08 syntax, and LilyPond actually makes use of the
> overloading resolution (which of the templates is called depends on
> where in the hierarchy the function that the function pointer refers to
> is defined) as part of the macro framework used here and thus it's not
> possible to manually resolve the override and kill all the prospective
> alternatives.

Besides, the way I read the "work-around" output, it still fails in
Clang.

> If the Clang developers refuse to fix the bug, we'll just stick with the
> current scheme: we don't need Clang to compile the MacOSX version of
> LilyPond.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG

>> No.  It's not C++08 syntax, and LilyPond actually makes use of the
>> overloading resolution (which of the templates is called depends on
>> where in the hierarchy the function that the function pointer
>> refers to is defined) as part of the macro framework used here and
>> thus it's not possible to manually resolve the override and kill
>> all the prospective alternatives.
>
> Besides, the way I read the "work-around" output, it still fails in
> Clang.

It seems that the code adds a second solution; you get an error for
the first one but the second succeeds (i.e., doesn't produce an error
on clang).


    Werner

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG
In reply to this post by Werner LEMBERG

> And answers are trickling in; see thread starting with
>
>   http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html

And here's the definite answer from a clang developer:

  The rule for determining when a base class function declaration
  introduced by a using-declaration is hidden by a derived class
  function declaration does not take the template parameter list into
  account: http://eel.is/c++draft/namespace.udecl#15.sentence-1

  So clang's behaviour is conforming and gcc's behaviour is not. At
  the very least, though, we should issue a warning for the using
  declaration, because this is a surprising rule.


    Werner

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

David Kastrup
Werner LEMBERG <[hidden email]> writes:

>> And answers are trickling in; see thread starting with
>>
>>   http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html
>
> And here's the definite answer from a clang developer:
>
>   The rule for determining when a base class function declaration
>   introduced by a using-declaration is hidden by a derived class
>   function declaration does not take the template parameter list into
>   account: http://eel.is/c++draft/namespace.udecl#15.sentence-1

Huh?  This link states:

    When a using-declarator brings declarations from a base class into a
    derived class, member functions and member function templates in the
    derived class override and/or hide member functions and member
    function templates with the same name, parameter-type-list,
    cv-qualification, and ref-qualifier (if any) in a base class (rather
    than conflicting).

The parameter-type-list is a different one in this example since they
contain a different member function pointer type.  Which is the reason
we need the whole hooplahoop in the first place.

>   So clang's behaviour is conforming and gcc's behaviour is not. At
>   the very least, though, we should issue a warning for the using
>   declaration, because this is a surprising rule.

I disagree.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG

>>   The rule for determining when a base class function declaration
>>   introduced by a using-declaration is hidden by a derived class
>>   function declaration does not take the template parameter list
>>   into account:
>>   http://eel.is/c++draft/namespace.udecl#15.sentence-1
>
> Huh?  This link states:
>
>     When a using-declarator brings declarations from a base class
>     into a derived class, member functions and member function
>     templates in the derived class override and/or hide member
>     functions and member function templates with the same name,
>     parameter-type-list, cv-qualification, and ref-qualifier (if
>     any) in a base class (rather than conflicting).
>
> The parameter-type-list is a different one in this example since
> they contain a different member function pointer type.  Which is the
> reason we need the whole hooplahoop in the first place.

And another response:

  Isn’t it template-parameter-list that is different rather than
  parameter-type-list?

    http://eel.is/c++draft/dcl.fct#def:parameter-type-list
    http://eel.is/c++draft/temp#nt:template-parameter-list

[I must admit that I'm completely lost with those finicky C++
details.]


      Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: compilation with clang

Werner LEMBERG

And another follow-up.

  > Isn’t it template-parameter-list that is different rather than
  > parameter-type-list?
  >
  > http://eel.is/c++draft/dcl.fct#def:parameter-type-list
  > http://eel.is/c++draft/temp#nt:template-parameter-list

  Yes. The pieces are these:

  template
    <typename T> // template-parameter-list
  void f
    (int N) // parameter-type-list

  Both base and derived function template have a parameter-type-list
  of (). :(


    Werner
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel