[llvm] r199886 - Prevent repetitive warnings for unrecognized processors and features

[Sean Silva]

On Sat, Jan 25, 2014 at 12:33 PM, Artyom Skrobov <Artyom.Skrobov at arm.com>wrote:

> > Our documentation is not very good surrounding some of these larger
> > architectural issues. However, I can tell you with certainty that
> > this patch is unacceptable in it's current state. Revert it.
> >
> > As David said, it violates a fundamental invariant of the LLVM
> > codebase, which is that library users in the same process can
> > independently use the LLVM library. (There are some unfortunate
> > historical deviations from this that are being slowly mended,
> > but going new code doesn't regress on this: it's not up for debate).
>
> Reverted as r200083, but I'd still appreciate any hints as to what can be
> an
> acceptable solution to the issue at hand (preventing the same warning from
> being reported multiple times from multiple calling points).
>
> If the documentation doesn't guide around these larger architectural
> issues,
> and the existing code cannot be trusted as an example to follow, then the
> only remaining option I can see is to submit patches at random, until one
> of
> them gets accepted.
>
>
Well, there aren't very many things like this to trip over; like I said,
this is a pretty big issue: it's the "modular and reusable" in the
description of LLVM on the LLVM homepage. I wouldn't be able to so
confidently ask you to revert this if I wasn't sure that this is a major
principle that covers all the LLVM libraries. It's unlikely that you are
going to run into another issue like this, so keep sending the patches :)

However, if you do want a reason in the documentation that this patch
doesn't abide by, this is probably enough to disqualify the patch <
http://llvm.org/docs/CodingStandards.html#do-not-use-static-constructors>
(unless the SmallSet constructor is trivial).

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140128/b449bd0d/attachment.html>