This one seems to be fixed by the second patch and is looks similar to
the testcase that's already there - https://reviews.llvm.org/D59622
Different backtraces are moderately expected :)
On 3/21/19 6:58 AM, Alexander Kornienko wrote:
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
<mailto: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
