-
Notifications
You must be signed in to change notification settings - Fork 649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clang 16 regression causes compilation error in ssl_stream in C++20 mode #2648
Comments
FYI diff --git a/boost/beast/ssl/ssl_stream.hpp b/boost/beast/ssl/ssl_stream.hpp
index d7ce7c1..51cc9d0 100644
--- a/boost/beast/ssl/ssl_stream.hpp
+++ b/boost/beast/ssl/ssl_stream.hpp
@@ -673,7 +673,7 @@ public:
ssl_stream<SyncStream>& stream,
boost::system::error_code& ec);
- template<class AsyncStream, BOOST_BEAST_ASYNC_TPARAM1 TeardownHandler>
+ template<class AsyncStream, class TeardownHandler>
friend
void
async_teardown(
@@ -697,7 +697,7 @@ teardown(
}
template<class AsyncStream,
- BOOST_BEAST_ASYNC_TPARAM1 TeardownHandler = net::default_completion_token_t<beast::executor_type<AsyncStream>>>
+ class TeardownHandler = net::default_completion_token_t<beast::executor_type<AsyncStream>>>
void
async_teardown(
boost::beast::role_type role, Loosening requirements is not good but Clang bug lies exactly in applying concepts in template list so removing concepts helps. In original issue someone mentioned that you can also move concept to requires clause, like |
We are observing the following in openbmc/bmcweb with clang-16. ``` /usr/local/include/boost/beast/websocket/impl/read.hpp:695:17: error: call to 'async_teardown' is ambiguous ``` This was reported in boostorg#2648 and this change was suggested as a fix. Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Add a patch to work around the issue discussed in boostorg/beast#2648 and observed in bmcweb testing. This patch is only necessary in our Docker container, and not Yocto, because we only compile with clang or clang-tidy in the Docker environment. Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Change-Id: I9e68c74fd8ee1421bf9e49f9f6ce497c8b05a436
Am I correct that a corresponding fix did not make it into 1.83 despite the assigned milestone? |
Archlinux has bumped to clang 16 now, causing this error to pop up on my local development machine. clang15 package is available in extras, but would be nice to be able to build with clang 16 too. |
Similar issue over at FreeBSD and most likely several other places too. I'm not involved in boost development but maybe this would justify a patch release (i.e. boost |
Yeah, I forgot to merge in time. Issue is fixed in develop. Really sorry about that. |
Could you share a link to the particular commit so downstream package maintainers could potentially ship the patch if no |
The beast module fails to build with clang16+/ gcc13+, it was fixed in boostorg/beast@72c2eeb See more in GitHub issue: boostorg/beast#2648 (comment) While here, sync OS versions checks with ports to apply llvm usage
Hello, I want to notify you about llvm/llvm-project#60749
This is a problem in Clang itself but they decided that it is not a release blocker. Clang 16 will be released in a week and provided code is not compiling. Is it possible to change something on Beast side? It seems that the bug requires very specific conditions.
Sorry for inconvenience, we want to switch to LLVM 16 asap and I'm not sure what to do in light of this bug.
The text was updated successfully, but these errors were encountered: