
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 27, 2014, at 9:12 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 25, 2014 at 9:33 AM, Artyom Skrobov <span dir="ltr"><<a href="mailto:Artyom.Skrobov@arm.com" target="_blank">Artyom.Skrobov@arm.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Our documentation is not very good surrounding some of these larger<br>

> architectural issues. However, I can tell you with certainty that<br>

> this patch is unacceptable in it's current state. Revert it.<br>

><br>

> As David said, it violates a fundamental invariant of the LLVM<br>

> codebase, which is that library users in the same process can<br>

> independently use the LLVM library. (There are some unfortunate<br>

> historical deviations from this that are being slowly mended,<br>

> but going new code doesn't regress on this: it's not up for debate).<br>

<br>

</div>Reverted as r200083, but I'd still appreciate any hints as to what can be an<br>

acceptable solution to the issue at hand (preventing the same warning from<br>

being reported multiple times from multiple calling points).<br></blockquote><div><br></div><div>While Sean and I are trying to provide feedback where we can, at least for myself (and I suspect Sean would agree) we're not necessarily the owners in any of these areas and are by no means an authority to say "this must be reverted" - I appreciate you reverting this to continue discussion.<br>

<br>It'd probably be helpful if we had someone a little more "owner-y" to comment on how problematic this is, whether there's an obvious alternative, etc. I would guess Jim Grosbach, but not sure if he or others would be most helpful (the usual "how busy are they", "how knowledgable/authoritative are they", etc tradeoffs).</div></div></div></div></blockquote><div><br></div><div>Sounds like this discussion is moving in the right direction already, so I’ll just chime in here briefly to concur that a global variable (or file level or class level static, et. al.) is not an appropriate solution in modern LLVM.</div><div><br></div><div>FWIW, the existing code that unilaterally writes out to errs() from deep within the MC layer is also fundamentally broken, to put it mildly.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;">If the documentation doesn't guide around these larger architectural issues,<br>

and the existing code cannot be trusted as an example to follow, then the<br>

only remaining option I can see is to submit patches at random, until one of<br>

them gets accepted.</blockquote><div><br>My naive question would be: what's unique about this argument handling that leads to duplicate error messages here but not for any other argument handling? </div></div></div></div></blockquote><div><br></div><div>These are backend diagnostics only, right? I.e., they get issued by MC when using developer tools like llvm-mc, llc, et. al.. They’re certainly not diagnostics we would ever expect to see from, e.g., clang or other user-level front-end. As such, I don’t quite follow why we should care about filtering duplicates at all. I don’t oppose uniquing them or anything, I just don’t personally see it as a priority. YMMV.</div><div><br></div><div>-Jim</div></div></body></html>