<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 Dec 10, 2013, at 11:26 AM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 10/12/2013 18:03, Jim Grosbach
wrote:<br>
</div>
<blockquote cite="mid:C5C76C35-2DDD-4634-A8BE-7B754C673D9F@apple.com" type="cite">
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> That causes dissonance
between what the compiler sees and what lit.py sees for no
particularly good reason. One of the nice properties of lit
tests is that they're also valid compiler inputs, so trailing
slash is a bit unfortunate.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>How does the backslash break this in any way?</div>
</blockquote>
<br>
The backslash is interpreted by lit and the compiler in different
and incompatible ways.</div></blockquote><div><br></div><div>I disagree that this is different or incompatible.</div><div><br></div><div>In any case, you didn’t answer the more important of my two questions. What compilers interpret this code differently?</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
Spot the problem in this reduced example..<br>
<br>
<meta charset="utf-8">
<pre style="font-size: inherit; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="color: rgb(105, 105, 105);">// expected-no-diagnostics</span>
<span style="color: rgb(105, 105, 105);">// RUN: %clang_cc1 %s -verify -emit-llvm -o - | \</span>
__attribute__ <span style="color: rgb(128, 128, 48);">(</span><span style="color: rgb(128, 128, 48);">(</span>packed<span style="color: rgb(128, 128, 48);">)</span><span style="color: rgb(128, 128, 48);">)</span> <span style="color: rgb(105, 105, 105);">// no warning</span></pre></div></blockquote><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><pre style="font-size: inherit; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="color: rgb(128, 0, 0); font-weight: bold;">int</span> x<span style="color: rgb(128, 0, 128);">;</span></pre></div></blockquote><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><pre style="font-size: inherit; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="color: rgb(105, 105, 105);">// RUN: FileCheck %s</span>
<span style="color: rgb(105, 105, 105);">// CHECK: @x = common global i32 0, align 4</span></pre>
<br></div></blockquote><div><br></div><div>The attribute line is a comment, which any reasonable syntax highlighting editor will show you if you’re not used to looking for these sorts of things.</div><div><br></div><div>lit should generate a diagnostic (probably an error) for this code, however. It’s malformed.</div><div><br></div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
It is easier to get this wrong than it is to get it right -- in
effect, lit is encouraging use of backslash line continuations which
are guaranteed to change the meaning of the following line in C/C++
with a silent failure mode. This is concerning for a C/C++ compiler
test suite :-)<br>
<br>
It's problematic because the feature hides test issues in and of
itself by being incompatible with C, but moreover because it breaks
stock tools used to check code and comments due to the complex
sub-grammar introduced.<br>
<br>
It's really important to me that there's buy-in for this though --
the last thing I want is for people to say "Alp made my tests hard
to read" after the fact(!)<br></div></blockquote><div><br></div><div>If you necessitate test run lines longer than 80 characters, you will be making tests much harder for me to read.</div><div><br></div><div>This isn’t a problem with the lit RUN line syntax. It’s a problem with lit being far too permissive and not screaming when it sees obviously malformed code.</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
Cheers,<br>
Alp.<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.nuanti.com/">http://www.nuanti.com</a>
the browser experts
</pre>
</div>
</blockquote></div><br></body></html>