Hello Dimitry, Not sure if it is related but I'm seing some ports failing recently with errors bellow. ( error: no viable conversion from ... to 'bool' )
Similar fails appears at pkg-fallout: https://pkg-status.freebsd.org/beefy24/data/main-amd64-default/p226b23044ee7_s67df3130159/logs/binaryen-130.log https://pkg-status.freebsd.org/beefy24/data/main-amd64-default/p226b23044ee7_s67df3130159/logs/encryptpad-0.5.0.4_6.log >From node24 on main-n286352-73e0d6b44038: ``` c++ -o /wrkdirs/usr/ports/www/node24/work/node-v24.16.0/out/Release/obj.target/node_mksnapshot/tools/snapshot/node_mksnapshot.o ../tools/snapshot/node_mksnapshot.cc '-D_GLIBCXX_USE_CXX11_ABI=1' '-D_FILE_OFFSET_BITS=64' '-DNODE_OPENSSL_CONF_NAME=nodejs_conf' '-DNODE_OPENSSL_CERT_STORE' '-DICU_NO_USER_DATA_OVERRIDE' '-D__STDC_FORMAT_MACROS' '-DNODE_WANT_INTERNALS=1' '-DNODE_MKSNAPSHOT_USE_ARRAY_LITERALS=1' '-DHAVE_OPENSSL=1' '-DNODE_USE_NODE_CODE_CACHE=1' '-DHAVE_INSPECTOR=1' '-D__POSIX__' '-DNODE_USE_V8_PLATFORM=1' '-DNODE_HAVE_I18N_SUPPORT=1' '-DHAVE_AMARO=1' '-DHAVE_SQLITE=1' '-DHAVE_QUIC=0' -I../src -I../tools/msvs/genfiles -I../deps/v8/include -I../deps/cares/include -I../deps/uv/include -I../deps/ncrypto -I../deps/v8/third_party/simdutf -Wall -Wextra -Wno-unused-parameter -pthread -Wall -Wextra -Wno-unused-parameter -Werror=undefined-inline -Werror=extra-semi -Werror=ctad-maybe-unsupported -m64 -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -fno-strict-aliasing -std=gnu++20 -MMD -MF /wrkdirs/usr/ports/www/node24/work/node-v24.16.0/out/Release/.deps//wrkdirs/usr/ports/www/node24/work/node-v24.16.0/out/Release/obj.target/node_mksnapshot/tools/snapshot/node_mksnapshot.o.d.raw -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -c ../test/embedding/embedtest.cc:138:12: error: no viable conversion from 'node::EmbedderSnapshotData::Pointer' (aka 'unique_ptr<const EmbedderSnapshotData, DeleteSnapshotData>') to 'bool' 138 | assert(snapshot); | ^~~~~~~~ /usr/include/c++/v1/__memory/unique_ptr.h:276:64: note: explicit conversion function is not a candidate 276 | _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX23 explicit operator bool() const _NOEXCEPT { | ^ ../test/embedding/embedtest.cc:216:14: error: no viable conversion from 'node::EmbedderSnapshotData::Pointer' (aka 'unique_ptr<const EmbedderSnapshotData, DeleteSnapshotData>') to 'bool' 216 | assert(snapshot); | ^~~~~~~~ /usr/include/c++/v1/__memory/unique_ptr.h:276:64: note: explicit conversion function is not a candidate 276 | _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX23 explicit operator bool() const _NOEXCEPT { | ^ 2 errors generated. ``` Any clues? Thanks, Dimitry Andric <[email protected]> escreveu (segunda, 1/06/2026 à(s) 18:13): > The branch main has been updated by dim: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=86326398b73b81f84831fb5fc4c12d9219bc0f57 > > commit 86326398b73b81f84831fb5fc4c12d9219bc0f57 > Author: Dimitry Andric <[email protected]> > AuthorDate: 2026-06-01 17:10:11 +0000 > Commit: Dimitry Andric <[email protected]> > CommitDate: 2026-06-01 17:10:11 +0000 > > Merge commit 63c29df8eceb from llvm git (by Dmitry Polukhin): > > [Serialization] Fix assertion on re-deserialized friend template > spec… (#200566) > > …ialization in PCH (#198133) > > A friend function-template specialization declared inside a class > template is serialized into a PCH. When the class template is later > instantiated while loading the PCH, the friend specialization can be > deserialized re-entrantly (VisitFriendDecl -> VisitFunctionDecl -> > ... > -> VisitFunctionDecl for the same specialization) at the same time as > the canonical copy, producing two redeclarations of the same > specialization in the template's specialization set. > > ASTDeclReader::VisitFunctionDecl asserted that this collision could > only > happen when merging declarations from different modules. Since > 38b3d87bd384, friend functions defined inside dependent class > templates > are loaded eagerly, so the collision can now also occur within a > single > PCH/AST file (non-modules build), tripping the assertion: > > Assertion failed: (Reader.getContext().getLangOpts().Modules && > "already deserialized this template specialization"), function > VisitFunctionDecl > > The merge that follows (mergeRedeclarable) already links the two > redeclarations correctly regardless of whether modules are enabled, > so > the fix is to drop the modules-only assumption and let the merge run. > > Fixes https://github.com/llvm/llvm-project/issues/198133 > > This fixes (well, simply removes :) an assertion when building the > cad/OrcaSlicer port with precompiled headers turned on. > > PR: 295296 > MFC after: 3 days > --- > contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp | 2 -- > 1 file changed, 2 deletions(-) > > diff --git > a/contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp > b/contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp > index b918bfbd549c..87224fae5dbb 100644 > --- a/contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp > +++ b/contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp > @@ -989,8 +989,6 @@ void ASTDeclReader::VisitFunctionDecl(FunctionDecl > *FD) { > if (InsertPos) > CommonPtr->Specializations.InsertNode(FTInfo, InsertPos); > else { > - assert(Reader.getContext().getLangOpts().Modules && > - "already deserialized this template specialization"); > Existing = ExistingInfo->getFunction(); > } > } > > -- Nuno Teixeira FreeBSD UNIX: <[email protected]> Web: https://FreeBSD.org
