Issue building Valley on macOS Ventura 13.5.2

Development
1

Hi fellow devs,

I’m having a real pain building my plugin on macOS Ventura 13.5.2. I’m building it the standard way using ‘make’, except it has major issues building VecLPG.hpp.

The compiler, Apple Clang 15.0.0, spits out this during compilation:

src/Terrorform/../dsp/filters/VecLPG.hpp:18:22: error: expected member name or ';' after declaration specifiers
    __m128 __attack, __decay;
    ~~~~~~           ^
src/Terrorform/../dsp/filters/VecLPG.hpp:88:9: error: a type specifier is required for all declarations
        __decay = _mm_mul_ps(x, x);
        ^
src/Terrorform/../dsp/filters/VecLPG.hpp:89:9: error: a type specifier is required for all declarations
        __decay = _mm_mul_ps(__decay, x);
        ^
src/Terrorform/../dsp/filters/VecLPG.hpp:89:30: warning: keyword '__decay' will be made available as an identifier here [-Wkeyword-compat]
        __decay = _mm_mul_ps(__decay, x);
                             ^
src/Terrorform/../dsp/filters/VecLPG.hpp:90:9: error: a type specifier is required for all declarations
        __decay = _mm_mul_ps(__decay, x);
        ^
src/Terrorform/../dsp/filters/VecLPG.hpp:90:30: warning: keyword '__decay' will be made available as an identifier here [-Wkeyword-compat]
        __decay = _mm_mul_ps(__decay, x);
                             ^
src/Terrorform/../dsp/filters/VecLPG.hpp:91:9: error: a type specifier is required for all declarations
        __decay = _mm_mul_ps(__decay, x);
        ^
src/Terrorform/../dsp/filters/VecLPG.hpp:91:30: warning: keyword '__decay' will be made available as an identifier here [-Wkeyword-compat]
        __decay = _mm_mul_ps(__decay, x);
                             ^
src/Terrorform/../dsp/filters/VecLPG.hpp:92:9: error: a type specifier is required for all declarations
        __decay = _mm_mul_ps(__decay, x);
        ^
src/Terrorform/../dsp/filters/VecLPG.hpp:92:30: warning: keyword '__decay' will be made available as an identifier here [-Wkeyword-compat]
        __decay = _mm_mul_ps(__decay, x);
                             ^
src/Terrorform/../dsp/filters/VecLPG.hpp:93:9: error: a type specifier is required for all declarations
        __decay = _mm_sub_ps(_mm_set1_ps(0.999995f), __decay);
        ^
src/Terrorform/../dsp/filters/VecLPG.hpp:93:54: warning: keyword '__decay' will be made available as an identifier here [-Wkeyword-compat]
        __decay = _mm_sub_ps(_mm_set1_ps(0.999995f), __decay);
                                                     ^
src/Terrorform/../dsp/filters/VecLPG.hpp:94:31: warning: keyword '__decay' will be made available as an identifier here [-Wkeyword-compat]
        __envelope.fallRate = __decay;
                              ^

Now why do you suppose this is happening? It’s very odd considering I just pushed an update to the library and has been approved this very moment. Is this a bug in the compiler?

UPDATE:

It must be a bug in Apple Clang 15. After installing LLVM 17 from brew then symlinking the c++ command to the newer version of Clang, it builds just fine.

2

I think it’s a lucky coincidence it compiles with 17 more likely. C++ reserves variables stating with __ (double underscore) as language keywords so I think clang is right to complain here. My guess is the implementation of some internal clang 15 used __decay as a keyword and that conflicts with you. Probably in their std::decay header

3

Yeah, it’s funny how it singled out __decay and no other variable that has the double underscore prefix. Tbh, in my other work, I don’t use that anymore. This is a hangover from my the “house style”.

It could’ve have just said that rather throwing an error that usually happens if you forget your type specifier.

4

So it did say that.

But also the fact that a variable is reserved doesn’t mean it is used of course! Don’t think of it as getting unlucky with __decay, think of it as getting lucky with every other __ prefixed variable in your codebase!

Anyway you can see in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/type_traits the thing that blows you up.

template <class _Up, bool>
struct __decay {
    typedef _LIBCPP_NODEBUG_TYPE typename remove_cv<_Up>::type type;
};

So the typename warning is kinda correct, in that it is struggling to figure out something about the template.

But really the constraints here are the ones to follow (no double underscore prefix, no single underscore followed by an upper case letter, and nothing starting with an underscore in the global namespace).

2 Likes
5

Ah, so that’s what that warning meant. Thanks for clarifying that.

What gets me is that this variable was made back in 2019 when Terrorform was being developed, so it’s clearly a change to the sdk which now conflicted with it. Anyway, I’ll refactor all those underscores out, they’re completely unnecessary.

6

The sdk usually specifies the current version of gcc, I think. In any case, that’s what most of us tend to develop with. New versions bring in new changes…

7

Yeah they changed their implementation of std decay it looks like.

But they are allowed to. The compiler writers can avoid collisions by using the blessed names and __ (since you wouldn’t/shouldn’t use two different toolchains in one tu inter toolchain collisions are ok) so stay away from protected names and libc and SDK improvements won’t explode you basically

8

Yeah the library and docker will probably be fine. Valley is compiling with latest Xcode locally seems. And if Andrew updated the macos sdk then it would break in the toolchain etc…

9

I’ll consider this experience as a foreshadowing then :sweat_smile:

Thanks for the help with this. Developing modules over the years has taught me a lot about C++ and programming practices, and it’s nice to get advice and feedback from other devs :blush:

3 Likes