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
// template-p
>> 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
Werner LEMBERG 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
> introd
> 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 hid
David Kastrup writes:
> Werner LEMBERG 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
>> 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 poss
Werner LEMBERG 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 actua
> 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
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.
Werner LEMBERG 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/
>>> 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/0
>> 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 the
Werner LEMBERG 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,
>> 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
Werner LEMBERG 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'
[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
16 matches
Mail list logo