marzer / tomlplusplus

Header-only TOML config file parser and serializer for C++17.
https://marzer.github.io/tomlplusplus/
MIT License
1.53k stars 146 forks source link

Compiler error: call to 'print_to_stream' is ambiguous #167

Closed acronce closed 2 years ago

acronce commented 2 years ago

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
  1. Open the tomlplusplus.xcodeproj Xcode project.

  2. 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 commented 2 years ago

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

acronce commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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...