HomePhabricator

[lldb] Mark the implicit copy constructor as deleted when a move constructor is…

Authored by teemperor on Jan 20 2020, 5:02 AM.

Description

[lldb] Mark the implicit copy constructor as deleted when a move constructor is provided.

Summary:
CXXRecordDecls that have a move constructor but no copy constructor need to
have their implicit copy constructor marked as deleted (see C++11 [class.copy]p7, p18)
Currently we don't do that when building an AST with ClangASTContext which causes
Sema to realise that the AST is malformed and asserting when trying to create an implicit
copy constructor for us in the expression:

Assertion failed: ((data().DefaultedCopyConstructorIsDeleted || needsOverloadResolutionForCopyConstructor())
    && "Copy constructor should not be deleted"), function setImplicitCopyConstructorIsDeleted, file include/clang/AST/DeclCXX.h, line 828.

In the test case there is a class NoCopyCstr that should have its copy constructor marked as
deleted (as it has a move constructor). When we end up trying to tab complete in the
IndirectlyDeletedCopyCstr constructor, Sema realises that the IndirectlyDeletedCopyCstr
has no implicit copy constructor and tries to create one for us. It then realises that
NoCopyCstr also has no copy constructor it could find via lookup. However because we
haven't marked the FieldDecl as having a deleted copy constructor the
needsOverloadResolutionForCopyConstructor() returns false and the assert fails.
needsOverloadResolutionForCopyConstructor() would return true if during the time we
added the NoCopyCstr FieldDecl to IndirectlyDeletedCopyCstr we would have actually marked
it as having a deleted copy constructor (which would then mark the copy constructor of
IndirectlyDeletedCopyCstr as needing overload resolution and Sema is happy).

This patch sets the correct mark when we complete our CXXRecordDecls (which is the time when
we know whether a copy constructor has been declared). In theory we don't have to do this if
we had a Sema around when building our debug info AST but at the moment we don't have this
so this has to do the job for now.

Reviewers: shafik

Reviewed By: shafik

Subscribers: aprantl, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72694