<div dir="ltr"><div>As Joel mentioned, I was at one point looking at implementing a CHECK-DEFINE. The idea was to define a variable inline without it actually matching any text. My use-case was where a string might want reusing in different runs of FileCheck, perhaps sometimes with a -NOT after it. The separate runs meant that using -D was not particularly appealing, as it just meant defining the string in two different places, whilst the -NOT suffix meant reusing the CHECK line itself wasn't viable either. Repeating the string also meant an update in one place might not get done in the other place, and since CHECK-NOT patterns are brittle, the test might start passing spuriously.<br></div><div><br></div><div>Simple example:</div><div><br></div><div># RUN: tool --success | FileCheck %s --check-prefix=SUCCESS</div><div># RUN: tool --fail | FileCheck %s --check-prefix=FAIL</div><div><br></div><div># SUCCESS: success message</div><div># FAIL-NOT: success message</div><div><br></div><div>Could become:</div><div><br></div><div>
<div># RUN: tool --success | FileCheck %s --check-prefixes=DEF,SUCCESS</div><div># RUN: tool --fail | FileCheck %s --check-prefixes=DEF,FAIL</div><div><br></div><div># DEF-DEFINE: [[MSG:success message]]<br></div><div>
<div># SUCCESS: [[MSG]]</div><div># FAIL-NOT: [[MSG]]</div><div><br></div><div>Unfortunately, this wasn't something I could sink much time into, and I've now put it on the back shelf for the foreseeable future. I'd be happy to put a patch up on Phabricator for others to pick up and work with, if they want?</div><div><br></div><div>I got a fair distance towards a prototype solution, but I wasn't particularly happy with the internal implementation, plus there were several cases where it either didn't work, or broke something else. The biggest problem I faced was that you probably don't want DEFINE directives defining variables that appear before it, but FileCheck's two-pass design made it tricky to handle that.</div><div><br></div><div>Back to the original problem: I haven't thought this through completely, but I wonder if you could use <a class="gmail_plusreply" id="m_2897624105040680082plusReplyChip-0" href="mailto:maskray@google.com" target="_blank">@Fāng-ruì Sòng</a>'s recent "extract" tool to split the pattern file up used by FileCheck somehow (see <a href="https://reviews.llvm.org/D83834">https://reviews.llvm.org/D83834</a>). By discarding the leading lines (using --no-leading-lines IIRC), you could make the @LINE directives more localised. Essentially it would look something like:</div><div><br></div><div>
<div># RUN: extract input1.c --no-leading-lines %s > %t1.c<br></div>
</div><div># RUN: do-a-thing %s | FileCheck %t1.c<br></div><div>#--- input1.c</div><div>this line causes some output # CHECK: [[@LINE]]: ...</div><div><br></div><div>Hope that helps!<br></div><div><br></div><div>James<br></div>
</div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 17 Jul 2020 at 21:57, Joel E. Denny via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 17, 2020 at 4:23 PM Nathan James <<a href="mailto:n.james93@hotmail.co.uk" target="_blank">n.james93@hotmail.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Joel,<br>
<br>
That sounds like a very nice idea and definitely a direction I could<br>
get behind. However I feel that outside the use case I suggested, this<br>
functionality would only be used to compress CHECK lines that contain<br>
repeated text, not saying its a bad or good thing though. WDYT?<br></blockquote><div><br></div><div>I can think of a few use cases:<br></div><div><br></div><div>1. Capturing `@LINE`, as you suggest.<br></div><div>2. Making a single directive's complex pattern more readable by extracting and naming components.<br></div><div>3. Avoiding the maintenance burden of repeating the same string, numeric, or pattern expression multiple times within a single directive or across multiple directives.</div><div><br></div><div>`-D` can sometimes help with #2 and #3. However, it still has to be repeated across multiple RUN lines in some cases. Moreover, it's sometimes better to define variables near their uses, but the RUN lines can be far away.<br></div><div><br></div><div>As an example of #2 and #3, I've occasionally written subtle patterns, such as `{{$[[:space:]]}}` for newline, that I wanted to use in multiple places. It's not immediately obvious what that pattern does, but `[[NL]]` would be much clearer and could be documented once at its definition.<br></div><div><br></div><div>It just occurred to me that the new directive might require a "CHECK-DEF-CONST" form that is processed before all other directives. Otherwise, forward-references wouldn't be possible. You might want forward-references for #1, for example.<br></div><div></div><div><br></div><div>Joel<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
~Nathan<br>
<br>
On Fri, 2020-07-17 at 14:52 -0400, Joel E. Denny via cfe-dev wrote:<br>
> Hi Nathan,<br>
> <br>
> On Fri, Jul 17, 2020 at 12:23 PM Nathan James via cfe-dev <<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> > Hello,<br>
> > <br>
> > I was wondering about extending FileCheck to enable creating line<br>
> > anchors. These are numeric variables that hold the value of the<br>
> > line<br>
> > number that where they were defined.<br>
> <br>
> I think something like this could be useful. However, I think it<br>
> would be more useful to have a general directive for defining<br>
> FileCheck variables inline without trying to capture from input. For<br>
> example:<br>
> <br>
> ```<br>
> #define BAD_FUNCTION() badFunction() // CHECK-DEFINE:<br>
> [[#BAD_FUNC:@LINE]]<br>
> // Further down in the file<br>
> BAD_FUNCTION();<br>
> CHECK-NOTES: [[@LINE-1]]:3: warning: called a bad function<br>
> CHECK-NOTES :[[#BAD_FUNC]]:3: note: expanded from macro<br>
> 'BAD_FUNCTION'<br>
> ```<br>
> <br>
> The exact syntax is debatable.<br>
> <br>
> I think this form is more useful because it can also define strings<br>
> or numerics (or maybe even patterns) to be reused in multiple<br>
> FileCheck directives across multiple FileCheck calls from different<br>
> RUN lines. Currently, you either have to capture such a variable<br>
> from the input or specify it with -D on every FileCheck call that<br>
> needs it.<br>
> <br>
> James Henderson: Weren't you working on something like this?<br>
> <br>
> Thanks.<br>
> <br>
> Joel<br>
> <br>
> > The motivation for this comes from test cases using clang-based<br>
> > diagnostics which often include notes attached to source locations<br>
> > in<br>
> > different parts of the file. In order to test for the correct<br>
> > location<br>
> > of the note, the line number has to be written explicitly or as an,<br>
> > often large, offset to the current line. This harms both<br>
> > readability<br>
> > and maintainability. Using this new system one could append a line<br>
> > of<br>
> > interest with an anchor-comment and refer back to it inside<br>
> > FileCheck.<br>
> > <br>
> > I have created a basic patch that implements this here <br>
> > <a href="https://reviews.llvm.org/D84037" rel="noreferrer" target="_blank">https://reviews.llvm.org/D84037</a> but it definitely needs a few looks<br>
> > over by people who are more clued up on the internal of FileCheck.<br>
> > <br>
> > The current syntax, based off this patch, is as follows:<br>
> > - Added a command line option called `anchor-prefix` which is a<br>
> > comma-seperated list of prefixes to be used when declaring anchors.<br>
> > This is defaulted to `LINE-ANCHOR`<br>
> > - To declare a anchor in the test file use<br>
> > `LINE-ANCHOR: ANCHOR_NAME`<br>
> > note: If you specify a different anchor-prefix using the<br>
> > command<br>
> > line, use that name instead of `LINE-ANCHOR`<br>
> > ANCHOR_NAME Follows the rules all other variable names aside<br>
> > from<br>
> > the fact it can't start with '$'.<br>
> > - When referring to an anchor in a check use the same numeric<br>
> > variable syntax that FileCheck already supports:<br>
> > `CHECK: [[#ANCHOR_NAME]][[#ANCHOR_NAME+1]]`<br>
> > <br>
> > Here is a brief (contrived) example of the usage of this:<br>
> > ```<br>
> > #define BAD_FUNCTION() badFunction() // LINE-ANCHOR: BAD_FUNC<br>
> > // Further down in the file<br>
> > BAD_FUNCTION();<br>
> > CHECK-NOTES: [[@LINE-1]]:3: warning: called a bad function<br>
> > CHECK-NOTES :[[#BAD-FUNC]]:3: note: expanded from macro<br>
> > 'BAD_FUNCTION'<br>
> > ```<br>
> > <br>
> > Regards,<br>
> > Nathan James<br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > cfe-dev mailing list<br>
> > <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
> <br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>