Allow custom attributes on clang-coverage

[mriccobene]

C++17 states that the compiler must ignore unknown attributes. This allows the users to annotate the code to convey more semantics or to use custom code analysis and manipulation tools. Also attributes cannot alter code semantics, so user defined attributes not recognized by the compiler can be safely ignored.

I found useful to annotate with a custom attribute [[long_running]] some methods that do not return immediately because they have a potentially infinite loop (i.e. gRPC stream reading loop) like this:

[[long_running]] void receive_messages(MessageQueue& messages, std::atomic<bool>& stopping);

The standard [[noreturn]] attribute is not adequate here because the method returns when it receives a stop signal.

But clang-coverage complains about unknown attributes.

I am proposing to allow custom attributes or at least custom attributes in the silkworm namespace: [[silkworm::long_running]]

[mriccobene]

Example error reported by clang-coverage:

In file included from /home/builder/project/node/silkworm/downloader/messages/OutboundGetBlockHeaders.cpp:22:
/home/builder/project/node/silkworm/downloader/header_downloader.hpp:73:7: error: unknown attribute 'long_running' ignored [-Werror,-Wunknown-attributes]
    [[long_running]] void receive_messages(MessageQueue& messages,       // subscribe with sentry to receive messages
      ^
1 error generated

[AndreaLanfranchi]

Yes you need to explicitly set -Wno-unknown-attributes in the compile options. The fact these attributes are ignored does not mean a warning is not emitted and as we treat all warnings as errors (-Werror -Wall -Wextra). This however, imho, opens another issue : what if we silently skip over unknown attributes and we have typos in attributes ? I mean [[nodscrd]] would be skipped while instead I do want a warning blocking the build as I meant it

[mriccobene]

The decision to ignore unrecognized attributes is not mine, it was taken by the c++ standardization committee.

Anyway I close this issue to not waste time, but we will lose the ability to better express some intent in the code.

[AndreaLanfranchi]

I'd keep it open instead (if you agree). Is useful, imho, to keep a trace of unresolved issues also for coding style techniques