[PATCH] D18123: Fix implicit copy ctor and copy assignment operator warnings when -Wdeprecated passed.

David Blaikie via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 14 15:24:39 PDT 2016


On Mon, Mar 14, 2016 at 3:07 PM, don hinton <hintonda at gmail.com> wrote:

> UnresolvedSetImpl isn't even constructible, much less copy constructible,
> but it is a public base class to UnresolvedSet, it it is -- at least until
> we turn it off by deleting the copy ctor.
>
> template <unsigned InlineCapacity> class UnresolvedSet :
>     public UnresolvedSetImpl {
>   SmallVector<DeclAccessPair, InlineCapacity> Decls;
> };
>
> But I'm not sure why we would need to since all it does is contain a
> SmallVector, and it supports all that behavior.  The problem here is that
> making UnresolvedSetImpl's ctor private and defining it, means you have to
> do something with the other ones as well.  I'm happy to turn the all off,
> but didn't see a good reason to do so.
>

Fair - I'm not too fussed, there, to be sure. If we're going to do it,
perhaps we should = default in the move ops too? (except those aren't
implicitly defaultible in MSVC... blah)

Maybe best to just wait until there's a need for them? I'm not sure. *shrug*


> As for libcxx and libcxxabi, they are 2 separate repos (at least in git).
>

Yep, wasn't expecting the fixes to go in the same code review or anything -
just wondering about direction.


>   Fixing libcxx is easy since it already defines a macro for
> throw()/noexcept.  Unfortunately, libcxxapi doesn't, though it's easy
> enough to define.
>

*nod*


>
> On Mon, Mar 14, 2016 at 5:33 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> UNresolvedSetImpl isn't copy constructible, so should it really be copy
>> assignable? (it looks like it only needs to be so because of LookupResult -
>> so once LookupResult is fixed, UnresolvedSetImpl can go back to the way it
>> was)
>>
>> Perhaps we should just wait for the fix for LookupResult copying in
>> SemaStmtAsm from Marina?
>>
>> Are you planning to cleanup -Wdeprecated in libcxx and libcxxabi too?
>>
>> I did most of the -Wdeprecated cleanup late last year - but when I tried
>> to turn it on I hit issues in various stdlibs, etc. It'd be great to finish
>> the cleanup, or suppress it in system headers, etc, and get it turned on.
>>
>> On Mon, Mar 14, 2016 at 12:29 PM, don hinton via cfe-commits <
>> cfe-commits at lists.llvm.org> wrote:
>>
>>> hintonda added a comment.
>>>
>>> Btw, what do you think about making -Wdeprecated the default for
>>> llvm/clang builds?
>>>
>>> With this change, llvm/clang will be clean.  However, libcxx and
>>> libcxxabi have a bunch of throw warnings.
>>>
>>>
>>> http://reviews.llvm.org/D18123
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160314/30995f96/attachment.html>


More information about the cfe-commits mailing list