Compiler error: call to 'print_to_stream' is ambiguous

[acronce]

Environment

toml++ version and/or commit hash:
501a80e

Compiler:
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Xcode 13.4.1 (13F100)

C++ standard mode:
Compiler default (i.e. GCC_C_LANGUAGE_STANDARD Xcode project env var defined as empty)

Target arch:
arm64

Library configuration overrides:
Nothing

Relevant compilation flags:
N/A

Describe the bug

I'm seeing the following compiler error when building most of the examples, including the parse_benchmark target:

In file included from ~/Sources/third_party/toml/tomlplusplus/tomlplusplus/examples/toml_to_json_transcoder.cpp:9:
In file included from ~/Sources/third_party/toml/tomlplusplus/tomlplusplus/include/toml++/toml.h:68:
~/Sources/third_party/toml/tomlplusplus/tomlplusplus/include/toml++/impl/path.inl:242:5: error: call to 'print_to_stream' is ambiguous
                                impl::print_to_stream(os, component.index());
                                ^~~~~~~~~~~~~~~~~~~~~

Steps to reproduce (or a small repro code sample)

1. Generate the project with the examples enabled:

cmake -B ../build --install-prefix=$HOME/Sources/third_party/toml/tomlplusplus/install -G Xcode -D BUILD_EXAMPLES=ON

2. Open the tomlplusplus.xcodeproj Xcode project.

3. Select the ALL_BUILD target and build.

Additional information

Not pretty, but I've worked around this by type coercing the index value:

impl::print_to_stream(os, (uint64_t)component.index());

[marzer]

Ah, interesting, thanks for the report! I detect ARM shenanigans. Time to bust out the RPi and give it a look.

[acronce]

Thanks for the quick response!

But I don't think this is arm specific. I see the same problem when building the x86_64 slice of a universal Apple Silicon binary.

It's probably related to the version of clang that Apple included with Xcode. It used to be that Apple's versioning obscured the underlying LLVM version. But according to the Xcode Wikipedia page, it is using LLVM 13 and clang 13.1.6. So at least for the moment Xcode's versioning and LLVM's match.

Have you tested with clang 13?

Of course I don't want to discourage you from breaking out your RPi ;-) Those are great little systems. I have way too many of them.

[marzer]

Have you tested with clang 13?

Yup, I test with clang 13 on my x86-64 dev machine. I think you're right in that it's down to Apple-clang. I've just identified some weirdness and am about to push some tentative fixes :)

Of course I don't want to discourage you from breaking out your RPi ;-) Those are great little systems. I have way too many of them.

Heh, the barrier to entry was low - it's already running 24/7 on my home network as a PiHole instance :D

[marzer]

Right, I think that's got it. If you're still having issues feel free to re-open this and I'll revisit it again tomorrow.

[acronce]

That fix works! Thanks so much for fixing this so quickly! It's much better than my hack work around.

Hopefully this comment doesn't reopen the issue.

On the RPi sub-thread, we've got a PiHole too! And Home Assistant, and OctoPi, and nodejs-poolController (all on their own RPis). Great stuff...