Thanks for the fix! Meanwhile, I found a couple of code samples that
trigger this assertion with a slightly different stack trace. Not sure if
they are substantially different though.
#1:
$ cat t.cc
inline namespace a {
class b typedef c;
}
class A {};
namespace a {
class b : A {};
} // namespace a
class d {
public:
operator c();
};
d e() { c f{e()}; }
$ clang-tidy -checks="-*,clang-analyzer*" t.cc -- -std=c++17
assert.h assertion failed at
llvm/tools/clang/lib/StaticAnalyzer/Core/RegionStore.cpp:2362 in (anonymous
namespace)::RegionBindingsRef (anonymous
namespace)::RegionStoreManager::bindStruct(RegionBindingsConstRef, const
clang::ento::TypedValueRegion *, clang::ento::SVal): CRD->isAggregate() &&
"Non-aggregates are constructed with a constructor!"
@ 0x5605d5ca35c6 __assert_fail
@ 0x5605d44064e4 (anonymous
namespace)::RegionStoreManager::bindStruct()
@ 0x5605d43fb058 (anonymous namespace)::RegionStoreManager::Bind()
@ 0x5605d43e5d2f clang::ento::ProgramState::bindLoc()
@ 0x5605d43975c5
clang::ento::ExprEngine::processPointerEscapedOnBind()
@ 0x5605d438f143 clang::ento::ExprEngine::evalBind()
@ 0x5605d43a46d3 clang::ento::ExprEngine::VisitDeclStmt()
@ 0x5605d438ddff clang::ento::ExprEngine::Visit()
@ 0x5605d438a7af clang::ento::ExprEngine::ProcessStmt()
@ 0x5605d438a498 clang::ento::ExprEngine::processCFGElement()
@ 0x5605d437e7f5 clang::ento::CoreEngine::HandlePostStmt()
@ 0x5605d437dbec clang::ento::CoreEngine::ExecuteWorkList()
@ 0x5605d40e7feb (anonymous
namespace)::AnalysisConsumer::HandleCode()
@ 0x5605d40d1dc5 (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit()
@ 0x5605d46ea43c clang::MultiplexConsumer::HandleTranslationUnit()
@ 0x5605d4854e54 clang::ParseAST()
@ 0x5605d46cb203 clang::FrontendAction::Execute()
@ 0x5605d4664451 clang::CompilerInstance::ExecuteAction()
@ 0x5605d45cef61
clang::tooling::FrontendActionFactory::runInvocation()
@ 0x5605d3d3e997
clang::tidy::runClangTidy()::ActionFactory::runInvocation()
@ 0x5605d45cecca clang::tooling::ToolInvocation::runInvocation()
@ 0x5605d45ce646 clang::tooling::ToolInvocation::run()
@ 0x5605d45d0f22 clang::tooling::ClangTool::run()
@ 0x5605d3d39c5f clang::tidy::runClangTidy()
@ 0x5605d0860c45 main
#2 is still being reduced.
On Wed, Mar 20, 2019 at 2:37 AM Artem Dergachev <noqnoq...@gmail.com> wrote:
> On 3/19/19 11:10 AM, Richard Smith wrote:
> > It sounds like there might be a missing check for
> > InitListExpr::isTransparent somewhere. (A transparent InitListExpr
> > should be treated as equivalent to its one and only subexpression.)
> > Either that, or the static analyzer isn't aware that an object of
> > class type can be initialized directly from a function call, not via a
> > constructor.
>
> Indeed, thanks! And, as usual, more bugs on top of that.
> (https://reviews.llvm.org/D59573)
>
> On 3/19/19 11:00 AM, Alexander Kornienko wrote:
> > just adding -std=c++17 on existing code (LLVM, for example ;) could
> > help uncover some of the issues
>
> Hmm, fair enough :D I'm glad i asked :)
>
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
