On Mon, Mar 14, 2016 at 3:30 PM, don hinton <hinto...@gmail.com> wrote:
> > > On Mon, Mar 14, 2016 at 6:24 PM, David Blaikie <dblai...@gmail.com> wrote: > >> >> >> On Mon, Mar 14, 2016 at 3:07 PM, don hinton <hinto...@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 <dblai...@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@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@lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>>>> >>>> >>>> >>> >> >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits