The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #29071 (refactor: Remove Span operator==, Use std::ranges::equal by maflcko)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

This is needed for stuff:

• std::ranges::equal, see refactor: Remove Span operator==, Use std::ranges::equal #29071
• std::source_location, see build: Enable -Wunreachable-code #28999 (comment)
• ...

FWIW on Ubuntu 20.04 I'm using pre-compiled binaries from https://github.com/llvm/llvm-project/releases/tag/llvmorg-18.1.4 with no issues.

Yeah, seems fine for test systems. I didn't want to suggest it, because https://discourse.llvm.org/t/rfc-improve-binary-security/78121/56 is still WIP.

Should this be dropped:

Should this be dropped:

Not sure what is wrong with Apple, but I don't have any insight into their XCode/Apple-Clang versioning and source code, so I think I'll just clarify in this comment that this needs Apple-Clang 16 (the meaning of which is unclear).

Ref:

/Applications/Xcode_15.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/map:1282:24: note: in instantiation of function template specialization 'std::__tree<std::__value_type<std::string_view, FuzzTarget>, std::__map_value_compare<std::string_view, std::__value_type<std::string_view, FuzzTarget>, std::less<std::string_view>>, std::allocator<std::__value_type<std::string_view, FuzzTarget>>>::__emplace_unique_key_args<std::string_view, const std::piecewise_construct_t &, std::tuple<const std::string_view &>, std::tuple<std::function<void (Span<const unsigned char>)> &&, FuzzTargetOptions &&>>' requested here
        return __tree_.__emplace_unique_key_args(__k,
                       ^
test/fuzz/fuzz.cpp:75:40: note: in instantiation of function template specialization 'std::map<std::string_view, FuzzTarget>::try_emplace<std::function<void (Span<const unsigned char>)>, FuzzTargetOptions>' requested here
    const auto [it, ins]{FuzzTargets().try_emplace(name, std::move(target), std::move(opts))};
                                       ^
test/fuzz/fuzz.cpp:62:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 2 were provided

https://github.com/bitcoin/bitcoin/actions/runs/9481386652/job/26124061545?pr=30263#step:7:2611

Looks like the Apple Clang shipping with Xcode 15, is based on Clang 15. Xcode 16 (still in beta) will ship with a Apple Clang based on Clang 16.

Concept ACK fa58c75

I'm on fedora and was able to build properly

uname -a
Linux fedora 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 17:37:39 UTC 2023 x86_64 GNU/Linux

clang --version
clang version 16.0.6 (Fedora 16.0.6-4.fc38)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

clang++ --version
clang version 16.0.6 (Fedora 16.0.6-4.fc38)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Looks like the Apple Clang shipping with Xcode 15, is based on Clang 15. Xcode 16 (still in beta) will ship with a Apple Clang based on Clang 16.

Well, for some reason it can compile ranges fine, without further changes, so at least to some extend it seems to be based on llvm 16 (maybe an intermediate random commit from the main dev branch)?

In any case, I am not changing the Xcode/macOS/Apple requirements here. Someone else can do it, if there is need for it and it is acceptable to do.

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

Rebased to remove a workaround that was added in the meantime.

@maflcko @TheCharlatan

Not a blocker at all, I just wonder if there is a verified recipe to get clang-16 for RISC-V platform?

Not a blocker at all, I just wonder if there is a verified recipe to get clang-16 for RISC-V platform?

Not sure what you mean, but this depends on your OS. You can install it normally. For example:

# apt install clang-16 && clang-16 --version 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
clang-16 is already the newest version (1:16.0.6-23ubuntu4).
0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.
Ubuntu clang version 16.0.6 (23ubuntu4)
Target: riscv64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

But this seems unrelated to this pull, or am I missing something?

@instagibbs @sr-gi maybe @mzumsande. This will likely affect you. Any feedback?

concept ACK

@instagibbs @sr-gi maybe @mzumsande. This will likely affect you. Any feedback?

I'm really not familiar with the build system, but I was able to build this without any changes in my setup on macOS 14.5 with clang 15.0.0

@instagibbs @sr-gi maybe @mzumsande. This will likely affect you. Any feedback?

Thanks - no objections, I've updated everywhere, so no longer affected by this.

Ported to the CMake-based build system in hebasto#263.