[Lldb-commits] [PATCH] D49990: Use rich mangling information in Symtab::InitNameIndexes()
Stefan Gränitz via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue Jul 31 05:30:54 PDT 2018
sgraenitz added inline comments.
================
Comment at: include/lldb/Symbol/Symtab.h:81-83
+ // No move
+ RichManglingInfo(RichManglingInfo &&) = delete;
+ RichManglingInfo &operator=(RichManglingInfo &&) = delete;
----------------
labath wrote:
> sgraenitz wrote:
> > labath wrote:
> > > This is implied by the deleted copy operations.
> > Which are implicitly deleted too, due to the existence of the destructor right? Does LLVM/LLDB have some kind of convention for it? I like to be explicit on ctors&assignment ("rule of 5"), because it aids error messages, but I would be fine with following the existing convention here.
> As far as I know, the presence of a destructor has no impact on the state of copy/move operations, so you still need to delete the copy operations explicitly.
>
> I don't know if there is an official policy on explicitly deleting move operations, but I don't remember seeing that style anywhere. However, I don't care much about that either.
> The generation of the implicitly-defined copy constructor is deprecated if T has a user-defined destructor or user-defined copy assignment operator.
https://en.cppreference.com/w/cpp/language/copy_constructor
Actually, copy has no implications here and move won't work on the const pointer. Thus I will just remove it :)
================
Comment at: source/Core/Mangled.cpp:325
return spec.CreateItaniumInfo();
} else {
----------------
> I think there is still something wrong with the diff. I can't see any of the callers of e.g. createItaniumInfo
Weird. The caller is here, but not shown as a change anymore..
https://reviews.llvm.org/D49990
More information about the lldb-commits
mailing list