<div dir="ltr">Hi Paul,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 14, 2018 at 4:29 PM,  <span dir="ltr"><<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_1777790081163769640m_-4206214940574875930WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u><u></u></span></p><span>

<p class="MsoNormal" style="margin-left:4.8pt">Speaking of wish lists, I've been thinking it would be nice to have some way to apply a NOT pattern among a range of matches:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:4.8pt">CHECK-NOT-PUSH: pattern<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><a name="m_1777790081163769640_m_-4206214940574875930__MailEndCompose"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Well, there is the `--implicit-check-not` option, which applies to the entire input text; it looks like you want it just for a subrange,
 though?</span></a></p></div></div></blockquote><div><br></div><div>Right.<br></div><div></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"><div lang="EN-US"><div class="gmail-m_1777790081163769640m_-4206214940574875930WordSection1"><p class="MsoNormal"><a name="m_1777790081163769640_m_-4206214940574875930__MailEndCompose"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">  If you aren't talking about DAGs, then repeating a CHECK-NOT between the other directives would work although it's pretty tedious (voice of experience) and easy to mess up (voice of experience).</span></a></p></div></div></blockquote><div><br></div><div>Agreed.<br></div><div></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"><div lang="EN-US"><div class="gmail-m_1777790081163769640m_-4206214940574875930WordSection1"><p class="MsoNormal"><a name="m_1777790081163769640_m_-4206214940574875930__MailEndCompose"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">If you have an example where CHECK-DAG-NOT would actually
 be useful,</span></a></p></div></div></blockquote><div><br></div><div></div><div>Yes, but I'd prefer a more general construct that also works without DAG.  That's why I suggested CHECK-NOT-PUSH and POP.  Jessica Paquette described a use case that I thought suggested she could benefit from that too, but it's possible I misunderstood her:<br></div><div><br></div><div><a href="http://lists.llvm.org/pipermail/llvm-dev/2018-May/123092.html">http://lists.llvm.org/pipermail/llvm-dev/2018-May/123092.html</a></div><div></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"><div lang="EN-US"><div class="gmail-m_1777790081163769640m_-4206214940574875930WordSection1"><p class="MsoNormal"><a name="m_1777790081163769640_m_-4206214940574875930__MailEndCompose"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> the formalism I'm going for does seem like it would help.</span></a></p></div></div></blockquote><div><br></div><div>Seems to help with either approach.</div><div><br></div><div>Thanks.<br></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"><div lang="EN-US"><div class="gmail-m_1777790081163769640m_-4206214940574875930WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0in 0in 0in 4pt">
<div>
<div style="border-color:rgb(181,196,223) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10pt;font-family:"Tahoma","sans-serif""> Joel E. Denny [mailto:<a href="mailto:jdenny.ornl@gmail.com" target="_blank">jdenny.ornl@gmail.com</a>]
<br>
<b>Sent:</b> Saturday, May 26, 2018 12:11 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [RFC] Formalizing FileCheck Features<u></u><u></u></span></p>
</div>
</div><div><div class="gmail-m_1777790081163769640h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi Paul,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">On Fri, May 25, 2018 at 10:40 AM, <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">> Should it be possible for CHECK-SAME match range to include newlines?<br>
 <br>
It is possible to write a regex that matches newlines.  Doing that in<br>
CHECK-SAME seems a bit odd but I don't think it's worth trying to forbid<br>
it.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">OK, so SAME has the sense of matching *starting* on the same line rather than *within* the same line.  Seems fine.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">> I'd note that, in the case of CHECK-NEXT, that choice can restrict what<br>
> CHECK-NEXT can match.  That is, it will complain about a match on the<br>
> previous line rather than skip it and look on the next line.<br>
<br>
Ah, so we could define CHECK-NEXT as: move the start of the search<br>
range past the first newline, then behaves as CHECK-SAME?<u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Right. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">But, appending {{.*$}} to the previous pattern should have the same<br>
effect if you have a CHECK-NEXT that runs into that problem.<u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So the current behavior is more flexible even if less intuitive at first glance (to me, at least).  It's also more consistent with the way search ranges work in general.<u></u><u></u></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think this subtlety and this tip should be mentioned in the user documentation. Also, because sometimes the previous directive isn't nearby or could be one of many directives due to multiple check prefixes, the docs should also offer
 this formula: <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">CHECK-SAME: {{.*}}<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">CHECK-NEXT: your pattern<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">And I<br>
do think it's valuable for SAME and NEXT to tell you they found<br>
matches but not on the line you asked for. So I'd prefer to leave these defined as they are.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">Agreed.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">>> CHECK-NOT: A sequence of NOT directives forms a NOT Group. The group<br>
>> is not executed immediately; instead the next non-NOT directive is<br>
>> executed first, and the start of that directive's match range becomes<br>
>> the end of the NOT Group's search range.<br>
><br>
> Based on the following, that wording is not quite right when a DAG<br>
> group follows, so there should probably be some note about that here.<br>
<br>
So, "the next non-NOT directive or DAG group is executed ... the start<br>
of that directive or group's match range ..." ?<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Sounds good.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">  <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">>>  (If the next directive is<br>
>> LABEL, it has already executed and has a match range, which is already<br>
>> the end of the search range.)  After the NOT Group's search range is<br>
>> defined, each NOT directive scans the range for a match, and fails if<br>
>> a match is found.<br>
>><br>
>> CHECK-DAG: A sequence of DAG directives forms a DAG Group. The group<br>
>> is not executed immediately; instead the next non-DAG directive is<br>
>> executed first, and the start of that directive's match range becomes<br>
>> the end of the DAG Group's search range.<br>
><br>
> That's definitely a change from the current behavior.  Currently, the<br>
> DAG group finds its own end based on the farthest match.<br>
<br>
Oh good catch.  Copy-thinko from the NOT description.  NOT is the only<br>
kind of directive that has deferred execution.<br>
 <br>
>>  If the next directive is<br>
>> CHECK-NOT, the end of the DAG Group's search range is<br>
>> unaffected.<br>
><br>
> Unaffected means that it's as if there's no following directive?  So<br>
> next CHECK-LABEL (possibly the implicit one at EOF)?  What if there's<br>
> a CHECK, CHECK-NEXT, or CHECK-SAME after all the DAGs and NOTs?<br>
<br>
If DAG doesn't have deferred execution then the end of the search range<br>
is the next (explicit or implicit) CHECK-LABEL point, end of story.<u></u><u></u></p>
</blockquote>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><u></u> <u></u></p>
</blockquote>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">>>  After all DAG directives run, the<br>
>> match range for the entire DAG Group extends from the start of the<br>
>> earliest match to the end of the latest match.  The end of that match<br>
>> range becomes the start of the search range for subsequent directives.<br>
><br>
> That last sentence contradicts the first few sentences: the subsequent<br>
> directive has already been matched.<br>
<br>
Right, fixing the previous bug means this sentence says the right thing.<u></u><u></u></p>
</blockquote>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yep, I agree it's fixed.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
> One point not addressed here is the start of the DAG group's search<br>
> range.  Currently, if the DAG group is preceded by a NOT group<br>
> preceded by a DAG group, the last DAG group's search range starts at<br>
> the start of the first DAG group's match range.  Any matches in the<br>
> first DAG group's match range produces a reordering error.  This is<br>
> somewhat similar to the CHECK-SAME and CHECK-NEXT behavior I mentioned<br>
> earlier: the search ranges permit invalid match ranges and then<br>
> complain about them in an effort to diagnose mistakes.  However, that<br>
> restricts what can be matched.<br>
><br>
> I'm not claiming that either behavior is best.  It's not clear to me.<br>
> The best use of DAG-NOT-DAG is very confusing to me.  An effort to<br>
> prescribe the right semantics to it needs to be informed by real use<br>
> cases, in my opinion.<br>
<br>
I did some email archaeology, and found this exchange on llvm-dev between<br>
myself and Michael Liao (original DAG implementor) 13 Mar 2016:<br>
<br>
pr> Commentary in FileCheck itself can easily be interpreted to mean the<br>
pr> intent was that –NOT would scan the region between the points defined<br>
pr> by the last match of the preceding DAG group (which the code gets<br>
pr> right) and the first match of the following DAG group (which the code<br>
pr> does not get right). But the commentary is not really that clear.<br>
<br>
ml> That's the intention of the original design. CHECK-NOT never occurs<br>
ml> before we find the start point (the start of file by default) and end<br>
ml> point (the end of file by default.) All other points are through other<br>
ml> CHECKs, including CHECK-DAG but excluding CHECK-NOT.  So that, if you<br>
ml> use CHECK-NOT, you need to be aware of how that range is defined. As<br>
ml> CHECK-DAG pattern matches a group of pattern in any order, the match<br>
ml> point of that group of CHECK-DAG (a consecutive CHECK-DAGs without any<br>
ml> other CHECKs interleaved) is always the point where one of that pgroup<br>
ml> is matched. If one CHECK-DAG is separated by any other CHECKs<br>
ml> (including CHECK-NOT) from preceding CHECK-DAGs, it is not in the<br>
ml> preceding group of CHECK-DAG. That's way how we could check the order<br>
ml> where a group of patterns should never occur before another group of<br>
ml> patterns.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks for digging that up.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">So, I believe my specification for the interaction between DAG and NOT<br>
does match the original intent.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I can't argue there.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">  Regarding the diagnostic aid, it does<br>
make some sequences really hard to match,<u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Arial","sans-serif"">Theoretically, I agree.  But do you know of a real use case where it's a problem?</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">and I don't have a general<u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
<div>
<div>
<div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">idea how to fix that (versus {{.*$}} for the similar NEXT situation).<u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Me neither.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">It's also a reasonable continuation of the behavior of plain CHECK, in
<br>
that a second CHECK doesn't search the prior text to complain about <br>
ordering issues.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Good point.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The main difference I see is that DAG is specifically about unordered text (and it might vary from run to run in the parallel programs I'm thinking of), so the chances of accidental reordering might be higher than with plain CHECK.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
SAME and NEXT are, I think, a different category; that has to do with<br>
line-breaks that are not explicitly described by user-written patterns,<br>
and my own experience is that it's helpful to be told that something<br>
matches but isn't on the line I expected.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Agreed.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
So, I don't have a definitive answer for changing DAG-NOT-DAG, but<br>
intuitively the spec makes sense to me and my inclination is to think<br>
the diagnostic isn't hugely valuable.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">You might be right. Again, I find it hard to think of solid arguments about DAG-NOT-DAG because it seems like such an unlikely use case.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">You mentioned Chris Lattner's point.  DAG-NOT-DAG was the first thing that came to my mind.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">DAG-NOT-DAG is a weird case where (1) you want two or more consecutive but non-overlapping DAG groups, and (2) you want to exclude certain patterns in between.  Strangely, with existing directives, you cannot accomplish #1 without #2, right? 
 Why do those go together?  It feels like a use case that arose from an accident in a language specification and not from a real need.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Well, maybe the best approach is just to go with a clear specification (as you have now) and hope for the best. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
>> Putting CHECK-SAME and CHECK-NEXT after CHECK-DAG now has defined<br>
>> behavior, but it's unlikely to be useful.<br>
><br>
> I believe they had predictable behavior before (their search ranges<br>
> started at the end of the match range for the entire CHECK-DAG), but<br>
> it's different with the above description (they define the end of the<br>
> search range for the preceding CHECK-DAG group).<br>
<br>
You're right, it was predictable before, and I am fixing the bug where<br>
the directive after DAG gets executed first so the range isn't affected.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Makes sense, so your specification keeps the old behavior.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Taking Chris Lattner's point into consideration, we might want to say<br>
SAME or NEXT after a DAG should be an error.  But we could also leave<br>
that for a later round.<u></u><u></u></p>
</blockquote>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">With your specification, I think the meaning of those cases is clear and potentially useful.  The only potential problem I see is that people who haven't studied your specification carefully might think SAME and NEXT constrain the end of
 the search range of the DAG group.  It might be worthwhile to emphasize in the docs that, no, really, DAG does not work that way.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Actually, I wish there were a way to do that for the sake of matching unordered text on a single line.  SAME after DAGs is as close as I can get to that.  Maybe we need a CHECK-DAG-SAME.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Speaking of wish lists, I've been thinking it would be nice to have some way to apply a NOT pattern among a range of matches:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">CHECK-NOT-PUSH: pattern<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">...</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">CHECK-NOT-POP:</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:rgb(34,34,34);background:white none repeat scroll 0% 0%">For example, with a pattern of {{.}} and DAGs in between PUSH and POP, I can check for an unordered set of strings while rejecting any other text among them.
 (Now that's a use case for DAG plus NOT that seems very clear to me.)</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Like normal NOT, PUSH's action would be deferred until the next directive or group.  At that point, it would push the specified NOT pattern along with the next non-NOT directive's match range
 end as its search range start. POP would pop and apply those using the previous non-NOT directive's match range start as its search range end.  The Rule would apply to its matches.  PUSH and POP would be like normal NOT in terms of their effect on neighboring
 directives: each would terminate any preceding DAG group, and, because there's no match in a successful run, each would have no effect on any neighboring directive's search range.  <span style="color:rgb(34,34,34);background:white none repeat scroll 0% 0%">PUSH and POP with no directives
 in between other than those in the NOT family would be an error.</span></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Your formal specification of FileCheck makes it straight-forward to describe this behavior precisely.</span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12pt"><br>
--paulr<br>
<br>
P.S. I am away next week but expect to keep an eye on the lists.<u></u><u></u></p>
</blockquote>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Sure.  Have fun.  No rush.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Joel<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>

</blockquote></div><br></div></div>