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

[David Blaikie via cfe-commits]

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

>
>
> On Mon, Mar 14, 2016 at 6:24 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>>
>> 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)
>>
>
> Yes, I included the move ops, move ctor and move assignment.
>
>
>>
>> Maybe best to just wait until there's a need for them? I'm not sure.
>> *shrug*
>>
>
> Sure, that's fine.  However, I think we should delete them in
> LookupResult, right?  The implicit copy and assignment ops are wrong and
> leak otherwise.
>

Yep. But I'm happy enough to wait for the correct fix from Marina there.


>
>
>>
>>
>>> 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/6cdbbb15/attachment-0001.html>