Ah, okay. Misunderstood. Will add shortly. thanks again... On Wed, Mar 16, 2016 at 1:55 PM, David Blaikie <dblai...@gmail.com> wrote:
> > > On Wed, Mar 16, 2016 at 10:52 AM, don hinton <hinto...@gmail.com> wrote: > >> -Werror clean is great. >> >> If you could add -Wdeprecated, then we wouldn't need to delete them -- >> the warning is only issued with -Wdeprecated is passed. >> > > Right, that's what I'm saying - add a fixme so that once we turn on the > deprecated warning (which will be an error, because enough of us use > -Werror) we should remove these deleted ops & just rely on the > warning/error. > > >> >> >> On Wed, Mar 16, 2016 at 1:49 PM, David Blaikie <dblai...@gmail.com> >> wrote: >> >>> >>> >>> On Wed, Mar 16, 2016 at 10:19 AM, don hinton <hinto...@gmail.com> wrote: >>> >>>> The current behavior, albeit deprecated, is to implicitly define >>>> these. Therefore, it would be incorrect not to delete them if the implicit >>>> versions don't do the right thing. >>>> >>>> I'd be happy to add a FIXME, but I doubt they will ever be removed. At >>>> best, they'd be #ifdef'd away for some future compiler that no longer >>>> implicitly defines them. >>>> >>>> Just not sure it's worth it. Deleting them will be valid no matter >>>> what the future holds. >>>> >>> >>> Sure, but it's a lot of extra deletes (if you search the mailing list >>> for "author: dblaikie" and "deprecated" you'll find many other instances I >>> cleaned up, in which we'd have to explicitly delete these ops if that's >>> going to be our approach) >>> >>> I don't think we'd only ifdef them away. Keeping the clang build -Werror >>> clean is a pretty well established bar, so if anyone accidentally >>> introduced a call to any of these, we'd find/fix it pretty quickly as we do >>> other errors/mistakes, even when they're not hard language-required errors. >>> >>> >>>> >>>> On Wed, Mar 16, 2016 at 12:56 PM, David Blaikie <dblai...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Mar 16, 2016 at 7:54 AM, don hinton via cfe-commits < >>>>> cfe-commits@lists.llvm.org> wrote: >>>>> >>>>>> hintonda updated this revision to Diff 50823. >>>>>> hintonda added a comment. >>>>>> >>>>>> Address FIXME now that Sema::LookupInlineAsmField() has been fixed. >>>>>> >>>>>> >>>>>> http://reviews.llvm.org/D18123 >>>>>> >>>>>> Files: >>>>>> include/clang/AST/UnresolvedSet.h >>>>>> include/clang/Sema/Lookup.h >>>>>> >>>>>> Index: include/clang/Sema/Lookup.h >>>>>> =================================================================== >>>>>> --- include/clang/Sema/Lookup.h >>>>>> +++ include/clang/Sema/Lookup.h >>>>>> @@ -185,6 +185,9 @@ >>>>>> Shadowed(false) >>>>>> {} >>>>>> >>>>>> + LookupResult(const LookupResult &) = delete; >>>>>> + LookupResult & operator=(const LookupResult &) = delete; >>>>>> >>>>> >>>>> Not sure how much to bother explicitly deleting ops like this if >>>>> eventually the -Wdeprecated warning will just catch it that way. Maybe >>>>> leave a "FIXME: Remove these once the warning for deprecated copy ops is >>>>> enabled"? >>>>> >>>>> >>>>>> + >>>>>> ~LookupResult() { >>>>>> if (Diagnose) diagnose(); >>>>>> if (Paths) deletePaths(Paths); >>>>>> Index: include/clang/AST/UnresolvedSet.h >>>>>> =================================================================== >>>>>> --- include/clang/AST/UnresolvedSet.h >>>>>> +++ include/clang/AST/UnresolvedSet.h >>>>>> @@ -59,8 +59,11 @@ >>>>>> // UnresolvedSet. >>>>>> private: >>>>>> template <unsigned N> friend class UnresolvedSet; >>>>>> - UnresolvedSetImpl() {} >>>>>> - UnresolvedSetImpl(const UnresolvedSetImpl &) {} >>>>>> + UnresolvedSetImpl() = default; >>>>>> + UnresolvedSetImpl(const UnresolvedSetImpl &) = default; >>>>>> + UnresolvedSetImpl(UnresolvedSetImpl &&) = default; >>>>>> + UnresolvedSetImpl& operator=(const UnresolvedSetImpl &) = default; >>>>>> + UnresolvedSetImpl& operator=(UnresolvedSetImpl &&) = default; >>>>>> >>>>>> public: >>>>>> // We don't currently support assignment through this iterator, so >>>>>> we might >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
