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. > > >> 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