[llvm-dev] Adding [[nodiscard]] to Compiler.h

[Lang Hames via llvm-dev]

Thanks very much Justin. This is great work in general, and it'll be a huge
improvement for llvm::Error users.

- Lang.

On Fri, Oct 14, 2016 at 3:05 PM, Justin Bogner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Justin Bogner <mail at justinbogner.com> writes:
> > Chandler Carruth <chandlerc at google.com> writes:
> >> My 2 cents: get rid of LLVM_UNUSED_RESULT, and move to LLVM_NODISCARD.
> >>
> >> For compilers that support it, it should be a strict superset of
> features and
> >> functionality. The standard feature was written directly based on the
> clang
> >> warn_unused_result stuff.
> >>
> >> I would just migrate us onto the spelling and usage pattern that got
> >> standardized. All we have to lose are warnings from compilers other
> than Clang
> >> until they implement this feature. That seems like not a huge loss to me
> >> honestly.
> >
> > You might be right. It seems a bit unfortunate that we'd lose these
> > warnings on MSVC and gcc for the time being, but maybe that's better
> > than the usability cost of having two macros that expand to the same
> > thing.
> >
> > Do note though, if we do that this would mean clang is the only compiler
> > we can support this on at all without -std=c++17, since [[nodiscard]]
> > will trigger extension warnings in earlier standard modes.
>
> After talking to a few people it sounds like one LLVM_NODISCARD macro is
> the way to go - We have prior art for clang-only warnings; we have
> enough coverage building with clang that we'll still catch anything
> quickly; and having two macros that are so similar is confusing and
> difficult to use.
>
> I'll stage this as adding an LLVM_NODISCARD, converting in tree code to
> use it instead of LLVM_ATTRIBUTE_UNUSED_RESULT, then finally removing
> the old macro.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161014/94596237/attachment.html>