[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