Build failure with OSX 13

[jprjr]

Build failure with OSX 13

[MaxKellermann]

What code location does it complain about?

[jprjr]

Oh sorry! https://github.com/MusicPlayerDaemon/MPD/blob/45f81cde6ddf8dd8e80d9396566900d6e6e5e4d9/src/decoder/DecoderPlugin.cxx#L42

…

On May 25, 2023 4:35:33 AM EDT, Max Kellermann ***@***.***> wrote: What code location does it complain about? -- Reply to this email directly or view it on GitHub: #1820 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[MaxKellermann]

I don't see where the code asks the compiler to convert a string_view to a string - do you?

[jprjr]

I'm suspecting this may have to do with the clang version and that mine was a few versions old.

I went ahead and downloaded the latest xcode command-line tools and installed, and the error went away.

Using clang/llvm version 12 though, I do get the error - and wth clang/llvm version 13, I don't.

Using this minimal example:

#include <string>
#include <set>
#include <string_view>

bool SetContains(const std::set<std::string, std::less<>> &set, const std::string_view &key) {

    return set.contains(key);
}

Using clang-12:

% /usr/local/opt/llvm@12/bin/clang++  -std=c++20 -c test.cpp
test.cpp:7:25: error: no viable conversion from 'const std::string_view' (aka 'const basic_string_view<char>') to 'const std::set<std::string, std::less<>>::key_type' (aka 'const std::string')
    return set.contains(key);
                        ^~~
/usr/local/opt/llvm@12/bin/../include/c++/v1/string:821:5: note: candidate constructor not viable: no known conversion from 'const std::string_view' (aka 'const basic_string_view<char>') to 'const std::string &' for 1st argument
    basic_string(const basic_string& __str);
    ^
/usr/local/opt/llvm@12/bin/../include/c++/v1/string:826:5: note: candidate constructor not viable: no known conversion from 'const std::string_view' (aka 'const basic_string_view<char>') to 'std::string &&' for 1st argument
    basic_string(basic_string&& __str)
    ^
/usr/local/opt/llvm@12/bin/../include/c++/v1/string:839:5: note: candidate constructor template not viable: no known conversion from 'const std::string_view' (aka 'const basic_string_view<char>') to 'const char *' for 1st argument
    basic_string(const _CharT* __s) : __r_(__default_init_tag(), __default_init_tag()) {
    ^
/usr/local/opt/llvm@12/bin/../include/c++/v1/string:890:5: note: candidate constructor not viable: no known conversion from 'const std::string_view' (aka 'const basic_string_view<char>') to 'initializer_list<char>' for 1st argument
    basic_string(initializer_list<_CharT> __il);
    ^
/usr/local/opt/llvm@12/bin/../include/c++/v1/string:814:40: note: explicit constructor is not a candidate
    _LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& __a)
                                       ^
/usr/local/opt/llvm@12/bin/../include/c++/v1/string:876:18: note: explicit constructor is not a candidate
        explicit basic_string(const _Tp& __t);
                 ^
/usr/local/opt/llvm@12/bin/../include/c++/v1/set:797:35: note: passing argument to parameter '__k' here
    bool contains(const key_type& __k) const {return find(__k) != end();}
                                  ^
1 error generated.

My guess is the following is occurring, though I now wonder if this is a compiler bug?

So here:

MPD/src/decoder/DecoderPlugin.hxx

Line 43 in 45f81cd

std::set<std::string, std::less<>> (*suffixes_function)() noexcept = nullptr;

The function suffixes_function() is declared to return std::set<std::string, std::less<>>

Then here:

MPD/src/decoder/DecoderPlugin.cxx

Line 25 in 45f81cd

SetContains(const auto &set, const auto &key) noexcept

SetContains is declared as a function that accept (const auto &set, const auto &key)

Looking at

MPD/src/decoder/DecoderPlugin.cxx

Line 37 in 45f81cd

DecoderPlugin::SupportsSuffix(std::string_view suffix) const noexcept

since the suffix parameter is a string_view, and the suffixes_function returns a std::set<std::string, std::less<>>, the call to SetContains is essentially now SetContains(const std::set<std::string, std::less<>> &set, const std::string_view &key)

And apparently this out-of-date clang version I had considers that an error.

I'm guessing this can be closed since the fix is to just update to a newer clang, sorry for the noise.