r356222 - [analyzer] Support C++17 aggregates with bases without constructors.

[Alexander Kornienko via cfe-commits]

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 <noqnoqneo at 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 :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20190321/84b6de3d/attachment-0001.html>