<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">WRT how we parse clang -v, this is potentially an issue for anyone that uses LNT today. The code used to infer information about the compiler *always* tries to use clang -v.<div class=""><br class=""></div><div class="">You can see this here: <a href="https://github.com/llvm-mirror/lnt/blob/master/lnt/testing/util/compilers.py" class="">https://github.com/llvm-mirror/lnt/blob/master/lnt/testing/util/compilers.py</a> </div><div class=""><br class=""></div><div class="">Since this output is intended for human-readability, and not stable machine-consumption, this can cause some issues for people using LNT. For example, if there’s a bug in the human-readable output, or it changes in a way LNT doesn’t expect, you’ll *always* get a run order of 0. This can, in the worst case, result in an insignificant amount of data loss for regular testing. So, having at least a stable way to grab version information would be useful for some of the code we offer up in open source today.</div><div class=""><br class=""></div><div class="">- Jessica</div><div class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 18, 2019, at 9:49 AM, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This seems mostly harmless -- except that I'd be worried that people will actually use them, when they probably shouldn't. :)<div class=""><div class=""><br class=""></div><div class="">The __clang_revision_number__ value especially, being numeric, seems rather amenable for misuse. Having this as a standalone numeric value, I'd be worried that people would compare against a particular value, without realizing that it's effectively a meaningless number without knowing more about the branch you're talking about (which is rather non-trivial). At least the git hash is more-obviously not usable for ordering. But, exposing that also has some downsides, with lack of flexibility. If it's specified that it must be just a hash, it cannot hold additional info, for example that your build contains uncommitted changes.</div></div><div class=""><br class=""></div><div class=""><div class="">So, I guess it's not entirely clear to me what useful purpose these values can be used for, for which __clang_version__ isn't already sufficient. (You mention that bots are parsing clang -v -- but to what end?)</div><br class="gmail-Apple-interchange-newline"></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 5:13 PM JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class="">Hello <font face="Courier" class="">macro</font> enthusiasts!<div class=""><br class=""></div><div class="">By default, clang defines a lot of <font face="Courier" class="">macros</font> that allow developers to figure out things about the compiler that’s building them. I’m proposing that we add two more:</div><div class=""><ol class="gmail-m_2580823970329368752MailOutline"><li class=""><font face="Courier" class="">__clang_revision_number__</font> : an unsigned integer, representing the current branch’s revision number.</li><li class=""><font face="Courier" class="">__clang_commit_hash__</font> : a string containing a hexadecimal hash, representing the current checkout’s hash.</li></ol></div><div class="">These would be set by cmake when building LLVM, and make the most sense in a monorepo on git. There’s been discussion of clang revision number in the context of git migration, <a href="https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git" target="_blank" class="">captured on the git migration page</a>.</div><div class=""><br class=""></div><div class="">Here are examples of similar numbers we currently offer:</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""><font face="Courier" class="">auto major     = __clang_major__;      // 7</font></div><div class=""><font face="Courier" class="">auto minor     = __clang_minor__;      // 0</font></div><div class=""><font face="Courier" class="">auto patch     = __clang_patchlevel__; // 0</font></div><div class=""><font face="Courier" class="">auto version   = __clang_version__;    // "7.0.0 (tags/RELEASE_700/final 342594)”</font></div><div class=""><font face="Courier" class="">auto VERSION   = __VERSION__;          // "4.2.1 Compatible Clang 7.0.0 (tags/RELEASE_700/final 342594)”</font></div><div class=""><font face="Courier" class="">auto gnu_major = __GNUC__;             // 4</font></div><div class=""><font face="Courier" class="">auto gnu_minor = __GNUC_MINOR__;       // 2</font></div><div class=""><font face="Courier" class="">auto gnu_patch = __GNUC_PATCHLEVEL__;  // 1</font></div><div class=""><font face="Courier" class="">auto gxx_abi   = __GXX_ABI_VERSION;    // 1002</font></div></blockquote><div class=""><br class="">The two new values will be generally useful to tools that automatically handle revisions. For example, we currently have bots that parse <font face="Courier" class="">clang -v</font>, and that output is unfortunately aimed at humans (bots aren’t human). That’s broken in the past, and having these two values would help reduce the likelihood of breakage because macros have a pretty stable format and are easy to test.</div><div class=""><br class=""></div><div class="">Let us know what you think!</div><div class=""><br class=""></div><div class="">JF</div><div class=""><br class=""></div></div>_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>