<div dir="ltr"><div>Hi Paul,<br></div><div><br></div><div>I've inlined some minor suggestions and questions.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 14, 2018 at 4:38 PM,  <span dir="ltr"><<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Spec for the model, version 2.  If this survives I'll start on<br>
amendments to the FileCheck doc.<br>
--paulr<br>
<span class=""><br>
<br>
Basic Conceptual Model<br>
----------------------<br>
<br>
FileCheck should operate on the basis of these three fundamental<br>
concepts.<br></span></blockquote><div><br></div><div>"should operate" -> "operates"<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
(1) Search range.  This is some substring of the input text where one<br>
or more directives will do their pattern-matching magic.<br>
<br>
(2) Match range.  This is a substring of a search range where a<br>
directive (or in one case, a group of directives) has matched a<br>
pattern.<br>
<br>
(3) Directive groups.  These are sequences of adjacent directives that<br>
operate in a related way on a search range.  Directives within a group<br>
are processed in order, except as noted in the directive description.<br></span></blockquote><div><br></div><div>Is there an exception?<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
Finally we add The Rule:  No match ranges may overlap.<br>
<br>
<br>
</span><span class="">Directive Descriptions Based On Conceptual Model<br>
------------------------------<wbr>------------------<br>
<br>
Given the conceptual model, all directives can be defined in terms of<br>
it.<br>
<br>
</span><span class="">CHECK: Scans the search range for a pattern match. Fails if no match<br>
</span>is found.  The end of the match range becomes the start of the search<br>
range for subsequent directives.<br>
<br>
CHECK-SAME: Like CHECK, plus there must be zero newlines within the<br>
search range prior to the start of the match range.<br>
<br>
CHECK-NEXT: Like CHECK, plus there must be exactly one newline within<br>
the search range prior to the start of the match range.<br>
<br>
Note: This definition means CHECK-NEXT will fail if the pattern<br>
occurs both on the line where the search range starts, and on the<br>
(expected) next line.</blockquote><div><br></div><div>The first occurrence is sufficient for a failure.  Perhaps: "and on the" -> "even if it also occurs on the"<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  This can be avoided by putting a<br>
`CHECK-SAME: {{.*}}` before the CHECK-NEXT.  We could also avoid<br></blockquote><div><br></div><div>To make it clearer to the naive user you're not describing a second option he can also try as a user: "We could also avoid" -> "We could have implemented FileCheck to avoid" <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
this by defining the CHECK-NEXT search range to be just the following<br>
line of text.  We define CHECK-NEXT the way we do because it seems <br>
valuable to diagnose mismatches that are simply on the wrong line,<br>
and the problematic case is rare.<br></blockquote><div><br></div><div>By the way, do you think it would be helpful for the diagnostic to suggest the CHECK-SAME trick?<br></div><div><span class=""></span><br><span class=""></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
CHECK-LABEL: All LABEL directives are processed before any other<br>
</span>directives.  These directives have three effects.  First, they act like<br>
CHECK directives. Second, they partition the input text into disjoint<br>
<span class="">search ranges, delimited by the match ranges of the LABEL directives.<br>
</span>Third, they partition the remaining directives into Label Groups,<br>
<span class="">each of which operates on the corresponding search range.  For truly<br>
pedantic formalism, we can say there are implicit LABEL directives<br>
matching the start and end of the entire input text, thus all<br>
</span>non-LABEL directives are always in some Label Group and there is<br>
really nothing special about the end of the input text.<br>
<br>
CHECK-NOT: A sequence of one or more consecutive NOT directives forms<br>
<span class="">a NOT Group. The group is not executed immediately; instead the next <br>
</span>non-NOT directive (or DAG Group, if the next directive is DAG) is <br>
executed first, and the start of that directive's (or group's)<br>
match range becomes the end of the NOT Group's search range.  (If the <br>
<span class="">next directive is LABEL, it has already executed and has a match range, <br>
</span>which is already the end of the search range.  If the NOT is the last<br>
directive, the search range extends to the end of the input.)  After <br>
the NOT Group's search range is defined, each NOT directive in the<br>
group scans the range for a match, and fails if a match is found.<br>
<br>
CHECK-DAG: A sequence of one or more consecutive DAG directives forms<br>
a DAG Group. The search range for the group extends from the end of<br>
the previous match (or start of the input, if there is no previous<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
directive) to the start of the next LABEL match, or to the end of the<br>
input if there is no later LABEL.</blockquote><div><br></div><div>It reads to me like LABEL is relevant to the end but not the start.  You might replace "(or start of the input" with "(possibly a LABEL or start of the
 input".<br><div></div></div><div></div><div> </div><div>On the other hand, in most of your directive descriptions (see CHECK, CHECK-NEXT, and CHECK-SAME), you don't define the directive's own search range.  Instead, you define how that directive impacts the start of the next search range.<br></div><div><br></div><div>The only difference here is that you have an entire group of directives with the same search range.  As FileCheck grows new directives, perhaps a more maintainable way to describe the search ranges for NOT groups and DAG groups is as follows:</div><div><br></div><div>"The search range for every member of the group is the search range that any single CHECK directive would have if it were to replace the entire group."<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Each directive in the DAG group <br>
scans the search range of the group looking for a pattern match. A <br>
directive fails if no match is found. Per The Rule, match ranges for<br>
the individual DAG directives in a group may not overlap.</blockquote><div><br></div><div>The last sentence is ambiguous.  It could mean you'll get a diagnostic if they do overlap.  Perhaps say "Per The Rule, each group member skips past any match whose range overlaps the range of an earlier group member's match."<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  After all <br>
<span class="">DAG directives run, the match range for the entire DAG Group extends <br>
from the start of the earliest match to the end of the latest match.  <br>
The end of that match range becomes the start of the search range for <br>
subsequent directives.<br>
<br>
</span>Observations<br>
------------<br>
<br>
A CHECK-NOT surrounded by CHECK-DAG directives separates the DAGs into<br></blockquote><div><br></div><div>"A CHECK-NOT" -> "One or more CHECK-NOTs"<br></div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">disjoint groups, and does not permit matches from the two groups to<br>
overlap. DAG was originally implemented to detect and diagnose an<br>
</span>overlap in this situation, but the implementation worked only for the <br>
<span class="">first DAG after a NOT. This can lead to counter-intuitive behavior and <br>
potentially makes certain kinds of matches impossible.<br></span></blockquote><div><br></div><div>By the way, I have a patch that fixes the search ranges for DAG-NOT-DAG to match your formal description here.  I need to polish up the commit log, and then I'll post it for review.  It applies after my other patches because it was easier to implement that way.<br></div><div><br></div><div>Thanks.</div><div><br></div><div>Joel<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
</span>Technically, putting CHECK-SAME or CHECK-NEXT after CHECK-DAG has <br>
defined behavior, but it's unlikely to be useful, so FileCheck rejects<br>
that kind of sequence.  Similarly, putting SAME or NEXT as the<br>
first directive in a file likewise has defined behavior (matching<br>
precisely the first or second line respectively of the input text);<br>
however this is far more likely to be a mistake than to be useful, so<br>
again FileCheck rejects this.<br>
<br>
</blockquote></div><br></div></div></div></div>