llvm dev - Sep 2016 - RFC: FileCheck Enhancements

> On Aug 24, 2016, at 4:46 PM, Vedant Kumar via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>> 
>> On Aug 24, 2016, at 2:04 AM, Elena Lepilkina <Elena.Lepilkina at
synopsys.com> wrote:
>> 
>> Hi all,
>> 
>> Some discussions and comments were made in reviews. Much time has
already passed since last comment and uploading changed patches. I made small
summary report about features here, because there are some doubts about syntax
of some features and changes in patches and it'll be great to know more
opinions.
>> 
>> 1. FileCheck Enhancement - CHECK-WORD (https://reviews.llvm.org/D22353)
>> I replace special directives by flag --check-word, which turns on mode
for each directive in file.  It's obvious that this mode can be replaced
using \b assert, but current regexp library doesn't have support of this
assert and I have no answer to question about possibility of change current
library.
>> There was the discussion about that such mode can be made default, but
there were doubts about necessity of a lot of work for changing existing tests.
>> And I made experiment which proves that a lot of old tests will be
failed with such mode on.
>> Expected Passes    : 15810
>> Expected Failures  : 125
>> Unsupported Tests  : 195
>> Unexpected Passes  : 4
>> Unexpected Failures: 1128
> 
> I would rather not introduce churn in our tests by turning on --check-word
by
> default. I'm also not convinced that turning on --check-word at the
test level
> is the right move: having a CHECK-WORD directive is more flexible, and not
a
> serious inconvenience (as compared to writing "CHECK").
> 
> 
>> 
>> 2. FileCheck Enhancement - pattern templates (
https://reviews.llvm.org/D22403 <https://reviews.llvm.org/D22403>)
>> There are some doubts about syntax of templates. I agree that use of 
\#, \:, \= is quite different from usual characters in FileCheck and was chosen
because of same approach for escaping in regexp. Adrian Prantl suggested to use
double-brackets "[[" to escape.
>> Old syntax:
>> \#(template_name) - use of template 'template_name'. It can
occur in CHECK-PATTERN line, when description of one template includes other
templates described before. (Without quote, I don't know how escape # here)
>> \:(Variable_name)- template variable with name 'variable_name'
>> \:(variable_name)\=(value) - current value of template
variable(it's needed when you use template with variables).
>> Suggested new syntax:
>> [[#template_name]] - use of template 'template_name'. It can
occur in CHECK-PATTERN line, when description of one template includes other
templates described before. (Without quote, I don't know how escape # here)
>> [[:Variable_name]] - template variable with name
'variable_name'
>> [[:variable_name=value]] - current value of template variable(it's
needed when you use template with variables).
>> It'll be great to hear more opinions and suggestions about syntax.
May be someone has really good ideas. Then I'll be able to change it.
> 
> First, I want to recap the FileCheck workflow Elena is proposing:
> 
>  1. Define patterns using the CHECK-DEFINE-PATTERN directive. Defined
patterns
>     have a name and may optionally have parameters.
> 
>  2. Use defined patterns in the usual CHECK* directives.
> 
> This is similar to how FileCheck patterns work already. The difference is
> that the patterns are defined using a dedicated directive, *not* when the
> pattern is first encountered. E.g, here is what you can do today:
> 
>  // RUN: echo "%r1 %r2" | FileCheck %s
>  // CHECK: %[[register:[a-z]+]]1
>  // CHECK-SAME: %[[register]]2
> 
> With the proposed changes, we'll be able to write something like:
> 
>  // RUN: echo "%cmp %cmp" | FileCheck %s
>  // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
>  // CHECK: %[[register("1")]]
>  // CHECK-SAME: %[[register("2")]]
At first I thought that `register(n)` was some sort of macro, but if it is
suppose to be equivalent to the example above of what we do “today”, then using
“register(“1”)” is supposed to “capture” the ‘r’ part of the register on the
first match.
So you cannot reuse “register()” later to capture another expression. For
instance:

 // RUN: FileCheck %s
 // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
 // CHECK: %[[register("1")]]
 // CHECK-SAME: %[[register("2")]]
 // CHECK: %[[register("1")]]
 // CHECK-SAME: %[[register("2")]]
%r1 %r2
%reg1 %reg2 #will fail here.


If true, I find this confusing, if not, I missed something in your example.

— 
Mehdi


> 
> I saw "something like" because we haven't decided on the
syntax for defining
> and using patterns (that's what this thread is for). Briefly,
here's the syntax
> I'd like to use:
> 
>  // Defining patterns.
>  CHECK-DEFINE-PATERN: <Name>(<Ident>, ...)?: <Pattern>
> 
>  Where <Pattern> is a list of <PatternElement>, and a
<PatternElement> is
>  either a regex ('{{' POSIX_REGEX '}}') or an argument
identifier (IDENT).
> 
>  // Using patterns.
>  CHECK: [[<Name>(<Argument>, ...)?]]
> 
> Fleshing this out some more, here is my candidate grammar (see the end of
this
> email for the current grammar):
> 
>  ACTION <- CHECK ':' MATCH '\n' ;
>  ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST? ':'
PATTERN_ELEMENT* '\n' ;
>  PARAMLIST <- '(' IDENT (',' IDENT)* ')' ;
>  PATTERN_ELEMENT <- IDENT ;
>  PATTERN_ELEMENT <- REGEX ;
>  MATCH <- ;
>  MATCH <- TEXT MATCH ;
>  MATCH <- REGEX MATCH ;
>  MATCH <- VAR MATCH ;
>  REGEX <- '{{' POSIX_REGEX '}}' ;
>  VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
>  VAR <- '[[' IDENT ARGLIST? ']]' ;
>  ARGLIST <- '(' ARG (',' ARG)* ')' ;
>  ARG <- "([^"]|\\")*" ;
> 
> 
>> 3. FileCheck Enhancement - repeats in regular expressions
(https://reviews.llvm.org/D22454 <https://reviews.llvm.org/D22454>),
FileCheck Enhancement - Including files (https://reviews.llvm.org/D22500
<https://reviews.llvm.org/D22500>), FileCheck Enhancement - Expressions
repeat for CHECK and CHECK-NEXT(https://reviews.llvm.org/D22501
<https://reviews.llvm.org/D22501>), FileCheck Enhancement -
CHECK-LABEL-DAG(https://reviews.llvm.org/D22502
<https://reviews.llvm.org/D22502>), FileCheck Enhancement -
prefixes-regular expressions (https://reviews.llvm.org/D22503
<https://reviews.llvm.org/D22503>)
>> There were no comments about these enhancements at all. Your opinions
are very important.
> 
> I personally am waiting for some version of D22403 to land in-tree before
> starting on the other reviews. This would help me gauge what others in the
> community are thinking and what they need.
> 
>> 
>> I hope that some of these changes will be useful for FileCheck users,
so I need your opinions to get opportunity for review to be resumed.
> 
> thanks,
> vedant
> 
> Original FileCheck grammar (shamelessly copied from the grammar Adrian
posted
> to D22403):
> 
>  ACTION <- CHECK ':' MATCH '\n' ;
>  MATCH <- ;
>  MATCH <- TEXT MATCH ;
>  MATCH <- REGEX MATCH ;
>  MATCH <- VAR MATCH ;
>  REGEX <- '{{' POSIX_REGEX '}}' ;
>  VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
>  VAR <- '[[' IDENT ']]' ;
> 
> 
>> 
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Elena Lepilkina
via llvm-dev
>> Sent: Wednesday, July 20, 2016 4:52 PM
>> To: vsk at apple.com <mailto:vsk at apple.com>
>> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>> 
>> List of last patches:
>> 
>> 1. FileCheck Enhancement - CHECK-WORD (llvm-commits was added later as
diff update) - https://reviews.llvm.org/D22353
<https://reviews.llvm.org/D22353> 2. FileCheck Enhancement - pattern
templates(llvm-commits was added later as diff update) -
https://reviews.llvm.org/D22403 <https://reviews.llvm.org/D22403> 3.
FileCheck Enhancement - repeats in regular expressions (new review with
llvm-commits) - https://reviews.llvm.org/D22454
<https://reviews.llvm.org/D22454> 4. FileCheck Enhancement - Including
files (new review with llvm-commits) - https://reviews.llvm.org/D22500
<https://reviews.llvm.org/D22500>
>> 5. FileCheck Enhancement - Expressions repeat for CHECK and CHECK-NEXT
(new review with llvm-commits)   - https://reviews.llvm.org/D22501
<https://reviews.llvm.org/D22501>
>> 6. FileCheck Enhancement - CHECK-LABEL-DAG (new review with
llvm-commits)  - https://reviews.llvm.org/D22502
<https://reviews.llvm.org/D22502> 7. FileCheck Enhancement -
prefixes-regular expressions (new review with llvm-commits) -
https://reviews.llvm.org/D22503 <https://reviews.llvm.org/D22503>
>> 
>> Thanks,
>> Elena.
>> 
>> -----Original Message-----
>> From: vsk at apple.com [mailto:vsk at apple.com]
>> Sent: Tuesday, July 19, 2016 8:42 PM
>> To: Elena Lepilkina <Elena.Lepilkina at synopsys.com>
>> Cc: Dean Michael Berris <dean.berris at gmail.com>; Mehdi Amini
<mehdi.amini at apple.com>; llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>> 
>> Hi Elena,
>> 
>> 
>>> On Jul 19, 2016, at 6:36 AM, Elena Lepilkina via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>> 
>>> Hi all,
>>> 
>>> I made new patches for most of changes with llvm-commits
subscriber. But two patches were updated, because there are a lot of comments
(patch for CHECK-WORD and patch for templates pattern). Will it be ok?
>> 
>> IMO it's fine to keep some of the original reviews if you don't
want to discard/recreate their state.
>> 
>> Please list the most up-to-date set of Phab URL's here, with a
little note next to the ones which did not initially CC llvm-commits.
>> 
>> Thanks again for working on this!
>> 
>> vedant
>> 
>>> 
>>> Thanks, Elena.
>>> 
>>> -----Original Message-----
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
>>> Dean Michael Berris via llvm-dev
>>> Sent: Tuesday, July 19, 2016 6:53 AM
>>> To: Mehdi Amini <mehdi.amini at apple.com>
>>> Cc: via llvm-dev <llvm-dev at lists.llvm.org>
>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>> 
>>> 
>>>> On 19 Jul 2016, at 04:18, Mehdi Amini via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>>>> 
>>>> We had a long thread about that a few weeks (months?) ago: the
conclusion (as I remember) was roughly a guideline to “always start a new
revision to have a proper mailing-list thread starting with context (i.e. patch
description)”
>>>> (and my dissident minority opinion that it is only worth it if
there
>>>> hasn’t been significant round of reviews going on on the
existing
>>>> revision)
>>>> 
>>> 
>>> Pardon me for missing that discussion, this may have already been
asked before: but is it possible to make arcanist default subscribe the correct
commits mailing list in the process? This should make it at least harder to
forget.
>>> 
>>> Cheers
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160831/4aa2d0e5/attachment-0001.html>

> At first I thought that `register(n)` was some sort of macro, but if it is
suppose to be equivalent to the example above of what we do “today”, then using
“register(“1”)” is supposed to “capture” the ‘r’ part of the register on the
first match.

This is a problem with my suggested gramamr (specifically: it doesn't
provide a
way to use defined patterns to capture text for later reference).  Fred brought
up that he was confused by this too.

One way to fix it is to use '@' before using patterns. I'll recap
the suggested
grammar and work through another example. Here's how you'd define a
pattern:

  CHECK-DEFINE-PATTERN: car(make, model, year): {{Found a }} make model {{, from
}} year

And here's how you'd use it, *without* capturing the text into a
variable:

  CHECK: [[@car("Honda", "Accord", "2009")]]

(Note, this matches the text: "Found a Honda Accord, from 2009".)

To use a pattern and capture the matched text in "MY_CAR", you'd
write:

  CHECK: [[MY_CAR @car("Honda", "Accord",
"2009")]]

This gives us an unambiguous way to capture text matched via a defined pattern,
which is visually distinct from how normal regex-based capturing works.

Note that subsequent uses of "MY_CAR" should work as expected (i.e,
you can do
'[[MY_CAR]]' later in the test).

Revised grammar:

   ACTION <- CHECK ':' MATCH '\n' ;
   ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST? ':'
PATTERN_ELEMENT* '\n' ;
   PARAMLIST <- '(' IDENT (',' IDENT)* ')' ;
   PATTERN_ELEMENT <- IDENT | REGEX;
   MATCH <- (TEXT | REGEX | PATTERN_USE | VAR)* ;
   REGEX <- '{{' POSIX_REGEX '}}' ;
   PATTERN_USE <- '[[' '@' IDENT ']]' ;
   VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
   VAR <- '[[' IDENT '@' IDENT ARGLIST? ']]' ;
   ARGLIST <- '(' ARG (',' ARG)* ')' ;
   ARG <- "([^"]|\\")*" ;

vedant
> On Aug 31, 2016, at 9:11 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
>> 
>> On Aug 24, 2016, at 4:46 PM, Vedant Kumar via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>>> 
>>> On Aug 24, 2016, at 2:04 AM, Elena Lepilkina <Elena.Lepilkina at
synopsys.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> Some discussions and comments were made in reviews. Much time has
already passed since last comment and uploading changed patches. I made small
summary report about features here, because there are some doubts about syntax
of some features and changes in patches and it'll be great to know more
opinions.
>>> 
>>> 1. FileCheck Enhancement - CHECK-WORD
(https://reviews.llvm.org/D22353)
>>> I replace special directives by flag --check-word, which turns on
mode for each directive in file.  It's obvious that this mode can be
replaced using \b assert, but current regexp library doesn't have support of
this assert and I have no answer to question about possibility of change current
library.
>>> There was the discussion about that such mode can be made default,
but there were doubts about necessity of a lot of work for changing existing
tests.
>>> And I made experiment which proves that a lot of old tests will be
failed with such mode on.
>>> Expected Passes    : 15810
>>> Expected Failures  : 125
>>> Unsupported Tests  : 195
>>> Unexpected Passes  : 4
>>> Unexpected Failures: 1128
>> 
>> I would rather not introduce churn in our tests by turning on
--check-word by
>> default. I'm also not convinced that turning on --check-word at the
test level
>> is the right move: having a CHECK-WORD directive is more flexible, and
not a
>> serious inconvenience (as compared to writing "CHECK").
>> 
>> 
>>> 
>>> 2. FileCheck Enhancement - pattern templates (
https://reviews.llvm.org/D22403)
>>> There are some doubts about syntax of templates. I agree that use
of  \#, \:, \= is quite different from usual characters in FileCheck and was
chosen because of same approach for escaping in regexp. Adrian Prantl suggested
to use double-brackets "[[" to escape.
>>> Old syntax:
>>> \#(template_name) - use of template 'template_name'. It can
occur in CHECK-PATTERN line, when description of one template includes other
templates described before. (Without quote, I don't know how escape # here)
>>> \:(Variable_name)- template variable with name
'variable_name'
>>> \:(variable_name)\=(value) - current value of template
variable(it's needed when you use template with variables).
>>> Suggested new syntax:
>>> [[#template_name]] - use of template 'template_name'. It
can occur in CHECK-PATTERN line, when description of one template includes other
templates described before. (Without quote, I don't know how escape # here)
>>> [[:Variable_name]] - template variable with name
'variable_name'
>>> [[:variable_name=value]] - current value of template
variable(it's needed when you use template with variables).
>>> It'll be great to hear more opinions and suggestions about
syntax. May be someone has really good ideas. Then I'll be able to change
it.
>> 
>> First, I want to recap the FileCheck workflow Elena is proposing:
>> 
>>  1. Define patterns using the CHECK-DEFINE-PATTERN directive. Defined
patterns
>>     have a name and may optionally have parameters.
>> 
>>  2. Use defined patterns in the usual CHECK* directives.
>> 
>> This is similar to how FileCheck patterns work already. The difference
is
>> that the patterns are defined using a dedicated directive, *not* when
the
>> pattern is first encountered. E.g, here is what you can do today:
>> 
>>  // RUN: echo "%r1 %r2" | FileCheck %s
>>  // CHECK: %[[register:[a-z]+]]1
>>  // CHECK-SAME: %[[register]]2
>> 
>> With the proposed changes, we'll be able to write something like:
>> 
>>  // RUN: echo "%cmp %cmp" | FileCheck %s
>>  // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
>>  // CHECK: %[[register("1")]]
>>  // CHECK-SAME: %[[register("2")]]
> 
> At first I thought that `register(n)` was some sort of macro, but if it is
suppose to be equivalent to the example above of what we do “today”, then using
“register(“1”)” is supposed to “capture” the ‘r’ part of the register on the
first match.
> So you cannot reuse “register()” later to capture another expression. For
instance:
> 
>  // RUN: FileCheck %s
>  // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
>  // CHECK: %[[register("1")]]
>  // CHECK-SAME: %[[register("2")]]
>  // CHECK: %[[register("1")]]
>  // CHECK-SAME: %[[register("2")]]
> %r1 %r2
> %reg1 %reg2 #will fail here.
> 
> 
> If true, I find this confusing, if not, I missed something in your example.
> 
> — 
> Mehdi
> 
> 
> 
>> 
>> I saw "something like" because we haven't decided on the
syntax for defining
>> and using patterns (that's what this thread is for). Briefly,
here's the syntax
>> I'd like to use:
>> 
>>  // Defining patterns.
>>  CHECK-DEFINE-PATERN: <Name>(<Ident>, ...)?:
<Pattern>
>> 
>>  Where <Pattern> is a list of <PatternElement>, and a
<PatternElement> is
>>  either a regex ('{{' POSIX_REGEX '}}') or an argument
identifier (IDENT).
>> 
>>  // Using patterns.
>>  CHECK: [[<Name>(<Argument>, ...)?]]
>> 
>> Fleshing this out some more, here is my candidate grammar (see the end
of this
>> email for the current grammar):
>> 
>>  ACTION <- CHECK ':' MATCH '\n' ;
>>  ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST?
':' PATTERN_ELEMENT* '\n' ;
>>  PARAMLIST <- '(' IDENT (',' IDENT)* ')' ;
>>  PATTERN_ELEMENT <- IDENT ;
>>  PATTERN_ELEMENT <- REGEX ;
>>  MATCH <- ;
>>  MATCH <- TEXT MATCH ;
>>  MATCH <- REGEX MATCH ;
>>  MATCH <- VAR MATCH ;
>>  REGEX <- '{{' POSIX_REGEX '}}' ;
>>  VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
>>  VAR <- '[[' IDENT ARGLIST? ']]' ;
>>  ARGLIST <- '(' ARG (',' ARG)* ')' ;
>>  ARG <- "([^"]|\\")*" ;
>> 
>> 
>>> 3. FileCheck Enhancement - repeats in regular expressions
(https://reviews.llvm.org/D22454), FileCheck Enhancement - Including files
(https://reviews.llvm.org/D22500), FileCheck Enhancement - Expressions repeat
for CHECK and CHECK-NEXT(https://reviews.llvm.org/D22501), FileCheck Enhancement
- CHECK-LABEL-DAG(https://reviews.llvm.org/D22502), FileCheck Enhancement -
prefixes-regular expressions (https://reviews.llvm.org/D22503)
>>> There were no comments about these enhancements at all. Your
opinions are very important.
>> 
>> I personally am waiting for some version of D22403 to land in-tree
before
>> starting on the other reviews. This would help me gauge what others in
the
>> community are thinking and what they need.
>> 
>>> 
>>> I hope that some of these changes will be useful for FileCheck
users, so I need your opinions to get opportunity for review to be resumed.
>> 
>> thanks,
>> vedant
>> 
>> Original FileCheck grammar (shamelessly copied from the grammar Adrian
posted
>> to D22403):
>> 
>>  ACTION <- CHECK ':' MATCH '\n' ;
>>  MATCH <- ;
>>  MATCH <- TEXT MATCH ;
>>  MATCH <- REGEX MATCH ;
>>  MATCH <- VAR MATCH ;
>>  REGEX <- '{{' POSIX_REGEX '}}' ;
>>  VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
>>  VAR <- '[[' IDENT ']]' ;
>> 
>> 
>>> 
>>> -----Original Message-----
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of Elena Lepilkina via llvm-dev
>>> Sent: Wednesday, July 20, 2016 4:52 PM
>>> To: vsk at apple.com
>>> Cc: llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>> 
>>> List of last patches:
>>> 
>>> 1. FileCheck Enhancement - CHECK-WORD (llvm-commits was added later
as diff update) - https://reviews.llvm.org/D22353 2. FileCheck Enhancement -
pattern templates(llvm-commits was added later as diff update) -
https://reviews.llvm.org/D22403 3. FileCheck Enhancement - repeats in regular
expressions (new review with llvm-commits) - https://reviews.llvm.org/D22454 4.
FileCheck Enhancement - Including files (new review with llvm-commits) -
https://reviews.llvm.org/D22500
>>> 5. FileCheck Enhancement - Expressions repeat for CHECK and
CHECK-NEXT (new review with llvm-commits)   - https://reviews.llvm.org/D22501
>>> 6. FileCheck Enhancement - CHECK-LABEL-DAG (new review with
llvm-commits)  - https://reviews.llvm.org/D22502 7. FileCheck Enhancement -
prefixes-regular expressions (new review with llvm-commits) -
https://reviews.llvm.org/D22503
>>> 
>>> Thanks,
>>> Elena.
>>> 
>>> -----Original Message-----
>>> From: vsk at apple.com [mailto:vsk at apple.com]
>>> Sent: Tuesday, July 19, 2016 8:42 PM
>>> To: Elena Lepilkina <Elena.Lepilkina at synopsys.com>
>>> Cc: Dean Michael Berris <dean.berris at gmail.com>; Mehdi
Amini <mehdi.amini at apple.com>; llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>> 
>>> Hi Elena,
>>> 
>>> 
>>>> On Jul 19, 2016, at 6:36 AM, Elena Lepilkina via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I made new patches for most of changes with llvm-commits
subscriber. But two patches were updated, because there are a lot of comments
(patch for CHECK-WORD and patch for templates pattern). Will it be ok?
>>> 
>>> IMO it's fine to keep some of the original reviews if you
don't want to discard/recreate their state.
>>> 
>>> Please list the most up-to-date set of Phab URL's here, with a
little note next to the ones which did not initially CC llvm-commits.
>>> 
>>> Thanks again for working on this!
>>> 
>>> vedant
>>> 
>>>> 
>>>> Thanks, Elena.
>>>> 
>>>> -----Original Message-----
>>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
>>>> Dean Michael Berris via llvm-dev
>>>> Sent: Tuesday, July 19, 2016 6:53 AM
>>>> To: Mehdi Amini <mehdi.amini at apple.com>
>>>> Cc: via llvm-dev <llvm-dev at lists.llvm.org>
>>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>>> 
>>>> 
>>>>> On 19 Jul 2016, at 04:18, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>>> 
>>>>> We had a long thread about that a few weeks (months?) ago:
the conclusion (as I remember) was roughly a guideline to “always start a new
revision to have a proper mailing-list thread starting with context (i.e. patch
description)”
>>>>> (and my dissident minority opinion that it is only worth it
if there
>>>>> hasn’t been significant round of reviews going on on the
existing
>>>>> revision)
>>>>> 
>>>> 
>>>> Pardon me for missing that discussion, this may have already
been asked before: but is it possible to make arcanist default subscribe the
correct commits mailing list in the process? This should make it at least harder
to forget.
>>>> 
>>>> Cheers
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Thanks Vedant, that answers perfectly my concern!

— 
Mehdi
> On Aug 31, 2016, at 12:56 PM, Vedant Kumar <vsk at apple.com> wrote:
> 
>> At first I thought that `register(n)` was some sort of macro, but if it
is suppose to be equivalent to the example above of what we do “today”, then
using “register(“1”)” is supposed to “capture” the ‘r’ part of the register on
the first match.
> 
> 
> This is a problem with my suggested gramamr (specifically: it doesn't
provide a
> way to use defined patterns to capture text for later reference).  Fred
brought
> up that he was confused by this too.
> 
> One way to fix it is to use '@' before using patterns. I'll
recap the suggested
> grammar and work through another example. Here's how you'd define a
pattern:
> 
>  CHECK-DEFINE-PATTERN: car(make, model, year): {{Found a }} make model {{,
from }} year
> 
> And here's how you'd use it, *without* capturing the text into a
variable:
> 
>  CHECK: [[@car("Honda", "Accord", "2009")]]
> 
> (Note, this matches the text: "Found a Honda Accord, from 2009".)
> 
> To use a pattern and capture the matched text in "MY_CAR",
you'd write:
> 
>  CHECK: [[MY_CAR @car("Honda", "Accord",
"2009")]]
> 
> This gives us an unambiguous way to capture text matched via a defined
pattern,
> which is visually distinct from how normal regex-based capturing works.
> 
> Note that subsequent uses of "MY_CAR" should work as expected
(i.e, you can do
> '[[MY_CAR]]' later in the test).
> 
> Revised grammar:
> 
>   ACTION <- CHECK ':' MATCH '\n' ;
>   ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST?
':' PATTERN_ELEMENT* '\n' ;
>   PARAMLIST <- '(' IDENT (',' IDENT)* ')' ;
>   PATTERN_ELEMENT <- IDENT | REGEX;
>   MATCH <- (TEXT | REGEX | PATTERN_USE | VAR)* ;
>   REGEX <- '{{' POSIX_REGEX '}}' ;
>   PATTERN_USE <- '[[' '@' IDENT ']]' ;
>   VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
>   VAR <- '[[' IDENT '@' IDENT ARGLIST? ']]' ;
>   ARGLIST <- '(' ARG (',' ARG)* ')' ;
>   ARG <- "([^"]|\\")*" ;
> 
> vedant
> 
>> On Aug 31, 2016, at 9:11 AM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
>> 
>>> 
>>> On Aug 24, 2016, at 4:46 PM, Vedant Kumar via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>>> 
>>>> 
>>>> On Aug 24, 2016, at 2:04 AM, Elena Lepilkina
<Elena.Lepilkina at synopsys.com> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> Some discussions and comments were made in reviews. Much time
has already passed since last comment and uploading changed patches. I made
small summary report about features here, because there are some doubts about
syntax of some features and changes in patches and it'll be great to know
more opinions.
>>>> 
>>>> 1. FileCheck Enhancement - CHECK-WORD
(https://reviews.llvm.org/D22353)
>>>> I replace special directives by flag --check-word, which turns
on mode for each directive in file.  It's obvious that this mode can be
replaced using \b assert, but current regexp library doesn't have support of
this assert and I have no answer to question about possibility of change current
library.
>>>> There was the discussion about that such mode can be made
default, but there were doubts about necessity of a lot of work for changing
existing tests.
>>>> And I made experiment which proves that a lot of old tests will
be failed with such mode on.
>>>> Expected Passes    : 15810
>>>> Expected Failures  : 125
>>>> Unsupported Tests  : 195
>>>> Unexpected Passes  : 4
>>>> Unexpected Failures: 1128
>>> 
>>> I would rather not introduce churn in our tests by turning on
--check-word by
>>> default. I'm also not convinced that turning on --check-word at
the test level
>>> is the right move: having a CHECK-WORD directive is more flexible,
and not a
>>> serious inconvenience (as compared to writing "CHECK").
>>> 
>>> 
>>>> 
>>>> 2. FileCheck Enhancement - pattern templates (
https://reviews.llvm.org/D22403)
>>>> There are some doubts about syntax of templates. I agree that
use of  \#, \:, \= is quite different from usual characters in FileCheck and was
chosen because of same approach for escaping in regexp. Adrian Prantl suggested
to use double-brackets "[[" to escape.
>>>> Old syntax:
>>>> \#(template_name) - use of template 'template_name'. It
can occur in CHECK-PATTERN line, when description of one template includes other
templates described before. (Without quote, I don't know how escape # here)
>>>> \:(Variable_name)- template variable with name
'variable_name'
>>>> \:(variable_name)\=(value) - current value of template
variable(it's needed when you use template with variables).
>>>> Suggested new syntax:
>>>> [[#template_name]] - use of template 'template_name'.
It can occur in CHECK-PATTERN line, when description of one template includes
other templates described before. (Without quote, I don't know how escape #
here)
>>>> [[:Variable_name]] - template variable with name
'variable_name'
>>>> [[:variable_name=value]] - current value of template
variable(it's needed when you use template with variables).
>>>> It'll be great to hear more opinions and suggestions about
syntax. May be someone has really good ideas. Then I'll be able to change
it.
>>> 
>>> First, I want to recap the FileCheck workflow Elena is proposing:
>>> 
>>> 1. Define patterns using the CHECK-DEFINE-PATTERN directive.
Defined patterns
>>>    have a name and may optionally have parameters.
>>> 
>>> 2. Use defined patterns in the usual CHECK* directives.
>>> 
>>> This is similar to how FileCheck patterns work already. The
difference is
>>> that the patterns are defined using a dedicated directive, *not*
when the
>>> pattern is first encountered. E.g, here is what you can do today:
>>> 
>>> // RUN: echo "%r1 %r2" | FileCheck %s
>>> // CHECK: %[[register:[a-z]+]]1
>>> // CHECK-SAME: %[[register]]2
>>> 
>>> With the proposed changes, we'll be able to write something
like:
>>> 
>>> // RUN: echo "%cmp %cmp" | FileCheck %s
>>> // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
>>> // CHECK: %[[register("1")]]
>>> // CHECK-SAME: %[[register("2")]]
>> 
>> At first I thought that `register(n)` was some sort of macro, but if it
is suppose to be equivalent to the example above of what we do “today”, then
using “register(“1”)” is supposed to “capture” the ‘r’ part of the register on
the first match.
>> So you cannot reuse “register()” later to capture another expression.
For instance:
>> 
>> // RUN: FileCheck %s
>> // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
>> // CHECK: %[[register("1")]]
>> // CHECK-SAME: %[[register("2")]]
>> // CHECK: %[[register("1")]]
>> // CHECK-SAME: %[[register("2")]]
>> %r1 %r2
>> %reg1 %reg2 #will fail here.
>> 
>> 
>> If true, I find this confusing, if not, I missed something in your
example.
>> 
>> — 
>> Mehdi
>> 
>> 
>> 
>>> 
>>> I saw "something like" because we haven't decided on
the syntax for defining
>>> and using patterns (that's what this thread is for). Briefly,
here's the syntax
>>> I'd like to use:
>>> 
>>> // Defining patterns.
>>> CHECK-DEFINE-PATERN: <Name>(<Ident>, ...)?:
<Pattern>
>>> 
>>> Where <Pattern> is a list of <PatternElement>, and a
<PatternElement> is
>>> either a regex ('{{' POSIX_REGEX '}}') or an
argument identifier (IDENT).
>>> 
>>> // Using patterns.
>>> CHECK: [[<Name>(<Argument>, ...)?]]
>>> 
>>> Fleshing this out some more, here is my candidate grammar (see the
end of this
>>> email for the current grammar):
>>> 
>>> ACTION <- CHECK ':' MATCH '\n' ;
>>> ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST?
':' PATTERN_ELEMENT* '\n' ;
>>> PARAMLIST <- '(' IDENT (',' IDENT)* ')'
;
>>> PATTERN_ELEMENT <- IDENT ;
>>> PATTERN_ELEMENT <- REGEX ;
>>> MATCH <- ;
>>> MATCH <- TEXT MATCH ;
>>> MATCH <- REGEX MATCH ;
>>> MATCH <- VAR MATCH ;
>>> REGEX <- '{{' POSIX_REGEX '}}' ;
>>> VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
>>> VAR <- '[[' IDENT ARGLIST? ']]' ;
>>> ARGLIST <- '(' ARG (',' ARG)* ')' ;
>>> ARG <- "([^"]|\\")*" ;
>>> 
>>> 
>>>> 3. FileCheck Enhancement - repeats in regular expressions
(https://reviews.llvm.org/D22454), FileCheck Enhancement - Including files
(https://reviews.llvm.org/D22500), FileCheck Enhancement - Expressions repeat
for CHECK and CHECK-NEXT(https://reviews.llvm.org/D22501), FileCheck Enhancement
- CHECK-LABEL-DAG(https://reviews.llvm.org/D22502), FileCheck Enhancement -
prefixes-regular expressions (https://reviews.llvm.org/D22503)
>>>> There were no comments about these enhancements at all. Your
opinions are very important.
>>> 
>>> I personally am waiting for some version of D22403 to land in-tree
before
>>> starting on the other reviews. This would help me gauge what others
in the
>>> community are thinking and what they need.
>>> 
>>>> 
>>>> I hope that some of these changes will be useful for FileCheck
users, so I need your opinions to get opportunity for review to be resumed.
>>> 
>>> thanks,
>>> vedant
>>> 
>>> Original FileCheck grammar (shamelessly copied from the grammar
Adrian posted
>>> to D22403):
>>> 
>>> ACTION <- CHECK ':' MATCH '\n' ;
>>> MATCH <- ;
>>> MATCH <- TEXT MATCH ;
>>> MATCH <- REGEX MATCH ;
>>> MATCH <- VAR MATCH ;
>>> REGEX <- '{{' POSIX_REGEX '}}' ;
>>> VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
>>> VAR <- '[[' IDENT ']]' ;
>>> 
>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of Elena Lepilkina via llvm-dev
>>>> Sent: Wednesday, July 20, 2016 4:52 PM
>>>> To: vsk at apple.com
>>>> Cc: llvm-dev at lists.llvm.org
>>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>>> 
>>>> List of last patches:
>>>> 
>>>> 1. FileCheck Enhancement - CHECK-WORD (llvm-commits was added
later as diff update) - https://reviews.llvm.org/D22353 2. FileCheck Enhancement
- pattern templates(llvm-commits was added later as diff update) -
https://reviews.llvm.org/D22403 3. FileCheck Enhancement - repeats in regular
expressions (new review with llvm-commits) - https://reviews.llvm.org/D22454 4.
FileCheck Enhancement - Including files (new review with llvm-commits) -
https://reviews.llvm.org/D22500
>>>> 5. FileCheck Enhancement - Expressions repeat for CHECK and
CHECK-NEXT (new review with llvm-commits)   - https://reviews.llvm.org/D22501
>>>> 6. FileCheck Enhancement - CHECK-LABEL-DAG (new review with
llvm-commits)  - https://reviews.llvm.org/D22502 7. FileCheck Enhancement -
prefixes-regular expressions (new review with llvm-commits) -
https://reviews.llvm.org/D22503
>>>> 
>>>> Thanks,
>>>> Elena.
>>>> 
>>>> -----Original Message-----
>>>> From: vsk at apple.com [mailto:vsk at apple.com]
>>>> Sent: Tuesday, July 19, 2016 8:42 PM
>>>> To: Elena Lepilkina <Elena.Lepilkina at synopsys.com>
>>>> Cc: Dean Michael Berris <dean.berris at gmail.com>; Mehdi
Amini <mehdi.amini at apple.com>; llvm-dev at lists.llvm.org
>>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>>> 
>>>> Hi Elena,
>>>> 
>>>> 
>>>>> On Jul 19, 2016, at 6:36 AM, Elena Lepilkina via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I made new patches for most of changes with llvm-commits
subscriber. But two patches were updated, because there are a lot of comments
(patch for CHECK-WORD and patch for templates pattern). Will it be ok?
>>>> 
>>>> IMO it's fine to keep some of the original reviews if you
don't want to discard/recreate their state.
>>>> 
>>>> Please list the most up-to-date set of Phab URL's here,
with a little note next to the ones which did not initially CC llvm-commits.
>>>> 
>>>> Thanks again for working on this!
>>>> 
>>>> vedant
>>>> 
>>>>> 
>>>>> Thanks, Elena.
>>>>> 
>>>>> -----Original Message-----
>>>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org]
On Behalf Of
>>>>> Dean Michael Berris via llvm-dev
>>>>> Sent: Tuesday, July 19, 2016 6:53 AM
>>>>> To: Mehdi Amini <mehdi.amini at apple.com>
>>>>> Cc: via llvm-dev <llvm-dev at lists.llvm.org>
>>>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>>>> 
>>>>> 
>>>>>> On 19 Jul 2016, at 04:18, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>>>> 
>>>>>> We had a long thread about that a few weeks (months?)
ago: the conclusion (as I remember) was roughly a guideline to “always start a
new revision to have a proper mailing-list thread starting with context (i.e.
patch description)”
>>>>>> (and my dissident minority opinion that it is only
worth it if there
>>>>>> hasn’t been significant round of reviews going on on
the existing
>>>>>> revision)
>>>>>> 
>>>>> 
>>>>> Pardon me for missing that discussion, this may have
already been asked before: but is it possible to make arcanist default subscribe
the correct commits mailing list in the process? This should make it at least
harder to forget.
>>>>> 
>>>>> Cheers
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> 
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

Yes, I now understand what you suggested.
>   CHECK-DEFINE-PATTERN: car(make, model, year): {{Found a }} make model {{,
from }} year
But I think that in pattern I should show that I use parameter. I thought that
patterns can also be simple strings. All strings should be regexs in pattern and
parameters can't be used in pattern in your example. But I want to use
parameters in regexs. For example, {{Found a \#make{2,4}}}. I need to know if
this parameter name or simple text. So I asked you before about syntax of
parameters usage during describing patterns.

Thanks,
Elena.

-----Original Message-----
From: vsk at apple.com [mailto:vsk at apple.com] 
Sent: Wednesday, August 31, 2016 10:57 PM
To: Mehdi Amini <mehdi.amini at apple.com>
Cc: Elena Lepilkina <Elena.Lepilkina at synopsys.com>; llvm-dev at
lists.llvm.org
Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
> At first I thought that `register(n)` was some sort of macro, but if it is
suppose to be equivalent to the example above of what we do “today”, then using
“register(“1”)” is supposed to “capture” the ‘r’ part of the register on the
first match.

This is a problem with my suggested gramamr (specifically: it doesn't
provide a way to use defined patterns to capture text for later reference). 
Fred brought up that he was confused by this too.

One way to fix it is to use '@' before using patterns. I'll recap
the suggested grammar and work through another example. Here's how you'd
define a pattern:

  CHECK-DEFINE-PATTERN: car(make, model, year): {{Found a }} make model {{, from
}} year

And here's how you'd use it, *without* capturing the text into a
variable:

  CHECK: [[@car("Honda", "Accord", "2009")]]

(Note, this matches the text: "Found a Honda Accord, from 2009".)

To use a pattern and capture the matched text in "MY_CAR", you'd
write:

  CHECK: [[MY_CAR @car("Honda", "Accord",
"2009")]]

This gives us an unambiguous way to capture text matched via a defined pattern,
which is visually distinct from how normal regex-based capturing works.

Note that subsequent uses of "MY_CAR" should work as expected (i.e,
you can do '[[MY_CAR]]' later in the test).

Revised grammar:

   ACTION <- CHECK ':' MATCH '\n' ;
   ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST? ':'
PATTERN_ELEMENT* '\n' ;
   PARAMLIST <- '(' IDENT (',' IDENT)* ')' ;
   PATTERN_ELEMENT <- IDENT | REGEX;
   MATCH <- (TEXT | REGEX | PATTERN_USE | VAR)* ;
   REGEX <- '{{' POSIX_REGEX '}}' ;
   PATTERN_USE <- '[[' '@' IDENT ']]' ;
   VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
   VAR <- '[[' IDENT '@' IDENT ARGLIST? ']]' ;
   ARGLIST <- '(' ARG (',' ARG)* ')' ;
   ARG <- "([^"]|\\")*" ;

vedant
> On Aug 31, 2016, at 9:11 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
>> 
>> On Aug 24, 2016, at 4:46 PM, Vedant Kumar via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>>> 
>>> On Aug 24, 2016, at 2:04 AM, Elena Lepilkina <Elena.Lepilkina at
synopsys.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> Some discussions and comments were made in reviews. Much time has
already passed since last comment and uploading changed patches. I made small
summary report about features here, because there are some doubts about syntax
of some features and changes in patches and it'll be great to know more
opinions.
>>> 
>>> 1. FileCheck Enhancement - CHECK-WORD 
>>> (https://reviews.llvm.org/D22353) I replace special directives by
flag --check-word, which turns on mode for each directive in file.  It's
obvious that this mode can be replaced using \b assert, but current regexp
library doesn't have support of this assert and I have no answer to question
about possibility of change current library.
>>> There was the discussion about that such mode can be made default,
but there were doubts about necessity of a lot of work for changing existing
tests.
>>> And I made experiment which proves that a lot of old tests will be
failed with such mode on.
>>> Expected Passes    : 15810
>>> Expected Failures  : 125
>>> Unsupported Tests  : 195
>>> Unexpected Passes  : 4
>>> Unexpected Failures: 1128
>> 
>> I would rather not introduce churn in our tests by turning on 
>> --check-word by default. I'm also not convinced that turning on 
>> --check-word at the test level is the right move: having a CHECK-WORD 
>> directive is more flexible, and not a serious inconvenience (as
compared to writing "CHECK").
>> 
>> 
>>> 
>>> 2. FileCheck Enhancement - pattern templates ( 
>>> https://reviews.llvm.org/D22403) There are some doubts about syntax
of templates. I agree that use of  \#, \:, \= is quite different from usual
characters in FileCheck and was chosen because of same approach for escaping in
regexp. Adrian Prantl suggested to use double-brackets "[[" to escape.
>>> Old syntax:
>>> \#(template_name) - use of template 'template_name'. It can
occur in
>>> CHECK-PATTERN line, when description of one template includes other
>>> templates described before. (Without quote, I don't know how
escape
>>> # here)
>>> \:(Variable_name)- template variable with name
'variable_name'
>>> \:(variable_name)\=(value) - current value of template
variable(it's needed when you use template with variables).
>>> Suggested new syntax:
>>> [[#template_name]] - use of template 'template_name'. It
can occur
>>> in CHECK-PATTERN line, when description of one template includes
other templates described before. (Without quote, I don't know how escape #
here) [[:Variable_name]] - template variable with name 'variable_name'
>>> [[:variable_name=value]] - current value of template
variable(it's needed when you use template with variables).
>>> It'll be great to hear more opinions and suggestions about
syntax. May be someone has really good ideas. Then I'll be able to change
it.
>> 
>> First, I want to recap the FileCheck workflow Elena is proposing:
>> 
>>  1. Define patterns using the CHECK-DEFINE-PATTERN directive. Defined
patterns
>>     have a name and may optionally have parameters.
>> 
>>  2. Use defined patterns in the usual CHECK* directives.
>> 
>> This is similar to how FileCheck patterns work already. The 
>> difference is that the patterns are defined using a dedicated 
>> directive, *not* when the pattern is first encountered. E.g, here is
what you can do today:
>> 
>>  // RUN: echo "%r1 %r2" | FileCheck %s  // CHECK: 
>> %[[register:[a-z]+]]1  // CHECK-SAME: %[[register]]2
>> 
>> With the proposed changes, we'll be able to write something like:
>> 
>>  // RUN: echo "%cmp %cmp" | FileCheck %s  //
CHECK-DEFINE-PATERN:
>> register(n): {{[a-z]+}}n  // CHECK: %[[register("1")]]  // 
>> CHECK-SAME: %[[register("2")]]
> 
> At first I thought that `register(n)` was some sort of macro, but if it is
suppose to be equivalent to the example above of what we do “today”, then using
“register(“1”)” is supposed to “capture” the ‘r’ part of the register on the
first match.
> So you cannot reuse “register()” later to capture another expression. For
instance:
> 
>  // RUN: FileCheck %s
>  // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n  // CHECK: 
> %[[register("1")]]  // CHECK-SAME: %[[register("2")]] 
// CHECK:
> %[[register("1")]]  // CHECK-SAME: %[[register("2")]]
> %r1 %r2
> %reg1 %reg2 #will fail here.
> 
> 
> If true, I find this confusing, if not, I missed something in your example.
> 
> —
> Mehdi
> 
> 
> 
>> 
>> I saw "something like" because we haven't decided on the
syntax for
>> defining and using patterns (that's what this thread is for). 
>> Briefly, here's the syntax I'd like to use:
>> 
>>  // Defining patterns.
>>  CHECK-DEFINE-PATERN: <Name>(<Ident>, ...)?:
<Pattern>
>> 
>>  Where <Pattern> is a list of <PatternElement>, and a 
>> <PatternElement> is  either a regex ('{{' POSIX_REGEX
'}}') or an argument identifier (IDENT).
>> 
>>  // Using patterns.
>>  CHECK: [[<Name>(<Argument>, ...)?]]
>> 
>> Fleshing this out some more, here is my candidate grammar (see the 
>> end of this email for the current grammar):
>> 
>>  ACTION <- CHECK ':' MATCH '\n' ;
>>  ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST?
':'
>> PATTERN_ELEMENT* '\n' ;  PARAMLIST <- '(' IDENT
(',' IDENT)* ')' ;
>> PATTERN_ELEMENT <- IDENT ;  PATTERN_ELEMENT <- REGEX ;  MATCH
<- ;
>> MATCH <- TEXT MATCH ;  MATCH <- REGEX MATCH ;  MATCH <- VAR
MATCH ;
>> REGEX <- '{{' POSIX_REGEX '}}' ;  VAR <-
'[[' IDENT ':' POSIX_REGEX
>> ']]' ;  VAR <- '[[' IDENT ARGLIST? ']]' ; 
ARGLIST <- '(' ARG (','
>> ARG)* ')' ;  ARG <- "([^"]|\\")*" ;
>> 
>> 
>>> 3. FileCheck Enhancement - repeats in regular expressions 
>>> (https://reviews.llvm.org/D22454), FileCheck Enhancement -
Including files (https://reviews.llvm.org/D22500), FileCheck Enhancement -
Expressions repeat for CHECK and CHECK-NEXT(https://reviews.llvm.org/D22501),
FileCheck Enhancement - CHECK-LABEL-DAG(https://reviews.llvm.org/D22502),
FileCheck Enhancement - prefixes-regular expressions
(https://reviews.llvm.org/D22503) There were no comments about these
enhancements at all. Your opinions are very important.
>> 
>> I personally am waiting for some version of D22403 to land in-tree 
>> before starting on the other reviews. This would help me gauge what 
>> others in the community are thinking and what they need.
>> 
>>> 
>>> I hope that some of these changes will be useful for FileCheck
users, so I need your opinions to get opportunity for review to be resumed.
>> 
>> thanks,
>> vedant
>> 
>> Original FileCheck grammar (shamelessly copied from the grammar 
>> Adrian posted to D22403):
>> 
>>  ACTION <- CHECK ':' MATCH '\n' ;
>>  MATCH <- ;
>>  MATCH <- TEXT MATCH ;
>>  MATCH <- REGEX MATCH ;
>>  MATCH <- VAR MATCH ;
>>  REGEX <- '{{' POSIX_REGEX '}}' ;
>>  VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ; 
VAR <- '[[' IDENT ']]' ;
>> 
>> 
>>> 
>>> -----Original Message-----
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
>>> Elena Lepilkina via llvm-dev
>>> Sent: Wednesday, July 20, 2016 4:52 PM
>>> To: vsk at apple.com
>>> Cc: llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>> 
>>> List of last patches:
>>> 
>>> 1. FileCheck Enhancement - CHECK-WORD (llvm-commits was added later
as diff update) - https://reviews.llvm.org/D22353 2. FileCheck Enhancement -
pattern templates(llvm-commits was added later as diff update) -
https://reviews.llvm.org/D22403 3. FileCheck Enhancement - repeats in regular
expressions (new review with llvm-commits) - https://reviews.llvm.org/D22454 4.
FileCheck Enhancement - Including files (new review with llvm-commits) -
https://reviews.llvm.org/D22500
>>> 5. FileCheck Enhancement - Expressions repeat for CHECK and
CHECK-NEXT (new review with llvm-commits)   - https://reviews.llvm.org/D22501
>>> 6. FileCheck Enhancement - CHECK-LABEL-DAG (new review with 
>>> llvm-commits)  - https://reviews.llvm.org/D22502 7. FileCheck 
>>> Enhancement - prefixes-regular expressions (new review with 
>>> llvm-commits) - https://reviews.llvm.org/D22503
>>> 
>>> Thanks,
>>> Elena.
>>> 
>>> -----Original Message-----
>>> From: vsk at apple.com [mailto:vsk at apple.com]
>>> Sent: Tuesday, July 19, 2016 8:42 PM
>>> To: Elena Lepilkina <Elena.Lepilkina at synopsys.com>
>>> Cc: Dean Michael Berris <dean.berris at gmail.com>; Mehdi
Amini
>>> <mehdi.amini at apple.com>; llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>> 
>>> Hi Elena,
>>> 
>>> 
>>>> On Jul 19, 2016, at 6:36 AM, Elena Lepilkina via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I made new patches for most of changes with llvm-commits
subscriber. But two patches were updated, because there are a lot of comments
(patch for CHECK-WORD and patch for templates pattern). Will it be ok?
>>> 
>>> IMO it's fine to keep some of the original reviews if you
don't want to discard/recreate their state.
>>> 
>>> Please list the most up-to-date set of Phab URL's here, with a
little note next to the ones which did not initially CC llvm-commits.
>>> 
>>> Thanks again for working on this!
>>> 
>>> vedant
>>> 
>>>> 
>>>> Thanks, Elena.
>>>> 
>>>> -----Original Message-----
>>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf
>>>> Of Dean Michael Berris via llvm-dev
>>>> Sent: Tuesday, July 19, 2016 6:53 AM
>>>> To: Mehdi Amini <mehdi.amini at apple.com>
>>>> Cc: via llvm-dev <llvm-dev at lists.llvm.org>
>>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>>> 
>>>> 
>>>>> On 19 Jul 2016, at 04:18, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>>> 
>>>>> We had a long thread about that a few weeks (months?) ago:
the conclusion (as I remember) was roughly a guideline to “always start a new
revision to have a proper mailing-list thread starting with context (i.e. patch
description)”
>>>>> (and my dissident minority opinion that it is only worth it
if
>>>>> there hasn’t been significant round of reviews going on on
the
>>>>> existing
>>>>> revision)
>>>>> 
>>>> 
>>>> Pardon me for missing that discussion, this may have already
been asked before: but is it possible to make arcanist default subscribe the
correct commits mailing list in the process? This should make it at least harder
to forget.
>>>> 
>>>> Cheers
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

About CHECK-WORD. There is no problem to return first patch with CHECK-WORD,
CHECK-WORD-SAME and etc.
I added option because there were a lot of opinions that add a lot of new
directives is a bad idea.

Thanks,
Elena.

From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
Sent: Wednesday, August 31, 2016 7:12 PM
To: Vedant Kumar <vsk at apple.com>
Cc: Elena Lepilkina <Elena.Lepilkina at synopsys.com>; llvm-dev at
lists.llvm.org
Subject: Re: [llvm-dev] RFC: FileCheck Enhancements


On Aug 24, 2016, at 4:46 PM, Vedant Kumar via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:


On Aug 24, 2016, at 2:04 AM, Elena Lepilkina <Elena.Lepilkina at
synopsys.com<mailto:Elena.Lepilkina at synopsys.com>> wrote:

Hi all,

Some discussions and comments were made in reviews. Much time has already passed
since last comment and uploading changed patches. I made small summary report
about features here, because there are some doubts about syntax of some features
and changes in patches and it'll be great to know more opinions.

1. FileCheck Enhancement - CHECK-WORD (https://reviews.llvm.org/D22353)
I replace special directives by flag --check-word, which turns on mode for each
directive in file.  It's obvious that this mode can be replaced using \b
assert, but current regexp library doesn't have support of this assert and I
have no answer to question about possibility of change current library.
There was the discussion about that such mode can be made default, but there
were doubts about necessity of a lot of work for changing existing tests.
And I made experiment which proves that a lot of old tests will be failed with
such mode on.
Expected Passes    : 15810
Expected Failures  : 125
Unsupported Tests  : 195
Unexpected Passes  : 4
Unexpected Failures: 1128

I would rather not introduce churn in our tests by turning on --check-word by
default. I'm also not convinced that turning on --check-word at the test
level
is the right move: having a CHECK-WORD directive is more flexible, and not a
serious inconvenience (as compared to writing "CHECK").




2. FileCheck Enhancement - pattern templates ( https://reviews.llvm.org/D22403)
There are some doubts about syntax of templates. I agree that use of  \#, \:, \=
is quite different from usual characters in FileCheck and was chosen because of
same approach for escaping in regexp. Adrian Prantl suggested to use
double-brackets "[[" to escape.
Old syntax:
\#(template_name) - use of template 'template_name'. It can occur in
CHECK-PATTERN line, when description of one template includes other templates
described before. (Without quote, I don't know how escape # here)
\:(Variable_name)- template variable with name 'variable_name'
\:(variable_name)\=(value) - current value of template variable(it's needed
when you use template with variables).
Suggested new syntax:
[[#template_name]] - use of template 'template_name'. It can occur in
CHECK-PATTERN line, when description of one template includes other templates
described before. (Without quote, I don't know how escape # here)
[[:Variable_name]] - template variable with name 'variable_name'
[[:variable_name=value]] - current value of template variable(it's needed
when you use template with variables).
It'll be great to hear more opinions and suggestions about syntax. May be
someone has really good ideas. Then I'll be able to change it.

First, I want to recap the FileCheck workflow Elena is proposing:

 1. Define patterns using the CHECK-DEFINE-PATTERN directive. Defined patterns
    have a name and may optionally have parameters.

 2. Use defined patterns in the usual CHECK* directives.

This is similar to how FileCheck patterns work already. The difference is
that the patterns are defined using a dedicated directive, *not* when the
pattern is first encountered. E.g, here is what you can do today:

 // RUN: echo "%r1 %r2" | FileCheck %s
 // CHECK: %[[register:[a-z]+]]1
 // CHECK-SAME: %[[register]]2

With the proposed changes, we'll be able to write something like:

 // RUN: echo "%cmp %cmp" | FileCheck %s
 // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
 // CHECK: %[[register("1")]]
 // CHECK-SAME: %[[register("2")]]

At first I thought that `register(n)` was some sort of macro, but if it is
suppose to be equivalent to the example above of what we do “today”, then using
“register(“1”)” is supposed to “capture” the ‘r’ part of the register on the
first match.
So you cannot reuse “register()” later to capture another expression. For
instance:

 // RUN: FileCheck %s
 // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
 // CHECK: %[[register("1")]]
 // CHECK-SAME: %[[register("2")]]
 // CHECK: %[[register("1")]]
 // CHECK-SAME: %[[register("2")]]
%r1 %r2
%reg1 %reg2 #will fail here.


If true, I find this confusing, if not, I missed something in your example.

—
Mehdi





I saw "something like" because we haven't decided on the syntax
for defining
and using patterns (that's what this thread is for). Briefly, here's the
syntax
I'd like to use:

 // Defining patterns.
 CHECK-DEFINE-PATERN: <Name>(<Ident>, ...)?: <Pattern>

 Where <Pattern> is a list of <PatternElement>, and a
<PatternElement> is
 either a regex ('{{' POSIX_REGEX '}}') or an argument
identifier (IDENT).

 // Using patterns.
 CHECK: [[<Name>(<Argument>, ...)?]]

Fleshing this out some more, here is my candidate grammar (see the end of this
email for the current grammar):

 ACTION <- CHECK ':' MATCH '\n' ;
 ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST? ':'
PATTERN_ELEMENT* '\n' ;
 PARAMLIST <- '(' IDENT (',' IDENT)* ')' ;
 PATTERN_ELEMENT <- IDENT ;
 PATTERN_ELEMENT <- REGEX ;
 MATCH <- ;
 MATCH <- TEXT MATCH ;
 MATCH <- REGEX MATCH ;
 MATCH <- VAR MATCH ;
 REGEX <- '{{' POSIX_REGEX '}}' ;
 VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
 VAR <- '[[' IDENT ARGLIST? ']]' ;
 ARGLIST <- '(' ARG (',' ARG)* ')' ;
 ARG <- "([^"]|\\")*" ;



3. FileCheck Enhancement - repeats in regular expressions
(https://reviews.llvm.org/D22454), FileCheck Enhancement - Including files
(https://reviews.llvm.org/D22500), FileCheck Enhancement - Expressions repeat
for CHECK and CHECK-NEXT(https://reviews.llvm.org/D22501), FileCheck Enhancement
- CHECK-LABEL-DAG(https://reviews.llvm.org/D22502), FileCheck Enhancement -
prefixes-regular expressions (https://reviews.llvm.org/D22503)
There were no comments about these enhancements at all. Your opinions are very
important.

I personally am waiting for some version of D22403 to land in-tree before
starting on the other reviews. This would help me gauge what others in the
community are thinking and what they need.



I hope that some of these changes will be useful for FileCheck users, so I need
your opinions to get opportunity for review to be resumed.

thanks,
vedant

Original FileCheck grammar (shamelessly copied from the grammar Adrian posted
to D22403):

 ACTION <- CHECK ':' MATCH '\n' ;
 MATCH <- ;
 MATCH <- TEXT MATCH ;
 MATCH <- REGEX MATCH ;
 MATCH <- VAR MATCH ;
 REGEX <- '{{' POSIX_REGEX '}}' ;
 VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
 VAR <- '[[' IDENT ']]' ;




-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Elena
Lepilkina via llvm-dev
Sent: Wednesday, July 20, 2016 4:52 PM
To: vsk at apple.com<mailto:vsk at apple.com>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: FileCheck Enhancements

List of last patches:

1. FileCheck Enhancement - CHECK-WORD (llvm-commits was added later as diff
update) - https://reviews.llvm.org/D22353 2. FileCheck Enhancement - pattern
templates(llvm-commits was added later as diff update) -
https://reviews.llvm.org/D22403 3. FileCheck Enhancement - repeats in regular
expressions (new review with llvm-commits) - https://reviews.llvm.org/D22454 4.
FileCheck Enhancement - Including files (new review with llvm-commits) -
https://reviews.llvm.org/D22500
5. FileCheck Enhancement - Expressions repeat for CHECK and CHECK-NEXT (new
review with llvm-commits)   - https://reviews.llvm.org/D22501
6. FileCheck Enhancement - CHECK-LABEL-DAG (new review with llvm-commits)  -
https://reviews.llvm.org/D22502 7. FileCheck Enhancement - prefixes-regular
expressions (new review with llvm-commits) - https://reviews.llvm.org/D22503

Thanks,
Elena.

-----Original Message-----
From: vsk at apple.com<mailto:vsk at apple.com> [mailto:vsk at apple.com]
Sent: Tuesday, July 19, 2016 8:42 PM
To: Elena Lepilkina <Elena.Lepilkina at
synopsys.com<mailto:Elena.Lepilkina at synopsys.com>>
Cc: Dean Michael Berris <dean.berris at gmail.com<mailto:dean.berris at
gmail.com>>; Mehdi Amini <mehdi.amini at
apple.com<mailto:mehdi.amini at apple.com>>; llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: FileCheck Enhancements

Hi Elena,



On Jul 19, 2016, at 6:36 AM, Elena Lepilkina via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Hi all,

I made new patches for most of changes with llvm-commits subscriber. But two
patches were updated, because there are a lot of comments (patch for CHECK-WORD
and patch for templates pattern). Will it be ok?

IMO it's fine to keep some of the original reviews if you don't want to
discard/recreate their state.

Please list the most up-to-date set of Phab URL's here, with a little note
next to the ones which did not initially CC llvm-commits.

Thanks again for working on this!

vedant



Thanks, Elena.

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Dean Michael Berris via llvm-dev
Sent: Tuesday, July 19, 2016 6:53 AM
To: Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at
apple.com>>
Cc: via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>
Subject: Re: [llvm-dev] RFC: FileCheck Enhancements



On 19 Jul 2016, at 04:18, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

We had a long thread about that a few weeks (months?) ago: the conclusion (as I
remember) was roughly a guideline to “always start a new revision to have a
proper mailing-list thread starting with context (i.e. patch description)”
(and my dissident minority opinion that it is only worth it if there
hasn’t been significant round of reviews going on on the existing
revision)

Pardon me for missing that discussion, this may have already been asked before:
but is it possible to make arcanist default subscribe the correct commits
mailing list in the process? This should make it at least harder to forget.

Cheers
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160901/536803f0/attachment.html>

I wanted to start making some change. But I thought and I don't understand
why it's necessary to add @.

// RUN: FileCheck %s
 // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
 // CHECK: %[[register("1")]]
 // CHECK-SAME: %[[register("2")]]
 // CHECK: %[[register("1")]]
 // CHECK-SAME: %[[register("2")]]

This example will be equivalent to 

// RUN: FileCheck %s
 // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
 // CHECK: %{{[a-z]+}}1
 // CHECK-SAME: %{{[a-z]+}}2
 // CHECK: %{{[a-z]+}}1
 // CHECK-SAME: %{{[a-z]+}}2

Now we have another syntax, but pattern work such way.

If it's necessary to use pattern in variables, we can made
[[REGISTER:%[[register(1)]]]].

May be it is more useful to change extra brackets with @, but in Mehdi's
example everything will be okay id I understood well.

Thanks, 
Elena.

-----Original Message-----
From: vsk at apple.com [mailto:vsk at apple.com] 
Sent: Wednesday, August 31, 2016 10:57 PM
To: Mehdi Amini <mehdi.amini at apple.com>
Cc: Elena Lepilkina <Elena.Lepilkina at synopsys.com>; llvm-dev at
lists.llvm.org
Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
> At first I thought that `register(n)` was some sort of macro, but if it is
suppose to be equivalent to the example above of what we do “today”, then using
“register(“1”)” is supposed to “capture” the ‘r’ part of the register on the
first match.

This is a problem with my suggested gramamr (specifically: it doesn't
provide a way to use defined patterns to capture text for later reference). 
Fred brought up that he was confused by this too.

One way to fix it is to use '@' before using patterns. I'll recap
the suggested grammar and work through another example. Here's how you'd
define a pattern:

  CHECK-DEFINE-PATTERN: car(make, model, year): {{Found a }} make model {{, from
}} year

And here's how you'd use it, *without* capturing the text into a
variable:

  CHECK: [[@car("Honda", "Accord", "2009")]]

(Note, this matches the text: "Found a Honda Accord, from 2009".)

To use a pattern and capture the matched text in "MY_CAR", you'd
write:

  CHECK: [[MY_CAR @car("Honda", "Accord",
"2009")]]

This gives us an unambiguous way to capture text matched via a defined pattern,
which is visually distinct from how normal regex-based capturing works.

Note that subsequent uses of "MY_CAR" should work as expected (i.e,
you can do '[[MY_CAR]]' later in the test).

Revised grammar:

   ACTION <- CHECK ':' MATCH '\n' ;
   ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST? ':'
PATTERN_ELEMENT* '\n' ;
   PARAMLIST <- '(' IDENT (',' IDENT)* ')' ;
   PATTERN_ELEMENT <- IDENT | REGEX;
   MATCH <- (TEXT | REGEX | PATTERN_USE | VAR)* ;
   REGEX <- '{{' POSIX_REGEX '}}' ;
   PATTERN_USE <- '[[' '@' IDENT ']]' ;
   VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
   VAR <- '[[' IDENT '@' IDENT ARGLIST? ']]' ;
   ARGLIST <- '(' ARG (',' ARG)* ')' ;
   ARG <- "([^"]|\\")*" ;

vedant
> On Aug 31, 2016, at 9:11 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
>> 
>> On Aug 24, 2016, at 4:46 PM, Vedant Kumar via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>>> 
>>> On Aug 24, 2016, at 2:04 AM, Elena Lepilkina <Elena.Lepilkina at
synopsys.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> Some discussions and comments were made in reviews. Much time has
already passed since last comment and uploading changed patches. I made small
summary report about features here, because there are some doubts about syntax
of some features and changes in patches and it'll be great to know more
opinions.
>>> 
>>> 1. FileCheck Enhancement - CHECK-WORD 
>>> (https://reviews.llvm.org/D22353) I replace special directives by
flag --check-word, which turns on mode for each directive in file.  It's
obvious that this mode can be replaced using \b assert, but current regexp
library doesn't have support of this assert and I have no answer to question
about possibility of change current library.
>>> There was the discussion about that such mode can be made default,
but there were doubts about necessity of a lot of work for changing existing
tests.
>>> And I made experiment which proves that a lot of old tests will be
failed with such mode on.
>>> Expected Passes    : 15810
>>> Expected Failures  : 125
>>> Unsupported Tests  : 195
>>> Unexpected Passes  : 4
>>> Unexpected Failures: 1128
>> 
>> I would rather not introduce churn in our tests by turning on 
>> --check-word by default. I'm also not convinced that turning on 
>> --check-word at the test level is the right move: having a CHECK-WORD 
>> directive is more flexible, and not a serious inconvenience (as
compared to writing "CHECK").
>> 
>> 
>>> 
>>> 2. FileCheck Enhancement - pattern templates ( 
>>> https://reviews.llvm.org/D22403) There are some doubts about syntax
of templates. I agree that use of  \#, \:, \= is quite different from usual
characters in FileCheck and was chosen because of same approach for escaping in
regexp. Adrian Prantl suggested to use double-brackets "[[" to escape.
>>> Old syntax:
>>> \#(template_name) - use of template 'template_name'. It can
occur in
>>> CHECK-PATTERN line, when description of one template includes other
>>> templates described before. (Without quote, I don't know how
escape
>>> # here)
>>> \:(Variable_name)- template variable with name
'variable_name'
>>> \:(variable_name)\=(value) - current value of template
variable(it's needed when you use template with variables).
>>> Suggested new syntax:
>>> [[#template_name]] - use of template 'template_name'. It
can occur
>>> in CHECK-PATTERN line, when description of one template includes
other templates described before. (Without quote, I don't know how escape #
here) [[:Variable_name]] - template variable with name 'variable_name'
>>> [[:variable_name=value]] - current value of template
variable(it's needed when you use template with variables).
>>> It'll be great to hear more opinions and suggestions about
syntax. May be someone has really good ideas. Then I'll be able to change
it.
>> 
>> First, I want to recap the FileCheck workflow Elena is proposing:
>> 
>>  1. Define patterns using the CHECK-DEFINE-PATTERN directive. Defined
patterns
>>     have a name and may optionally have parameters.
>> 
>>  2. Use defined patterns in the usual CHECK* directives.
>> 
>> This is similar to how FileCheck patterns work already. The 
>> difference is that the patterns are defined using a dedicated 
>> directive, *not* when the pattern is first encountered. E.g, here is
what you can do today:
>> 
>>  // RUN: echo "%r1 %r2" | FileCheck %s  // CHECK: 
>> %[[register:[a-z]+]]1  // CHECK-SAME: %[[register]]2
>> 
>> With the proposed changes, we'll be able to write something like:
>> 
>>  // RUN: echo "%cmp %cmp" | FileCheck %s  //
CHECK-DEFINE-PATERN:
>> register(n): {{[a-z]+}}n  // CHECK: %[[register("1")]]  // 
>> CHECK-SAME: %[[register("2")]]
> 
> At first I thought that `register(n)` was some sort of macro, but if it is
suppose to be equivalent to the example above of what we do “today”, then using
“register(“1”)” is supposed to “capture” the ‘r’ part of the register on the
first match.
> So you cannot reuse “register()” later to capture another expression. For
instance:
> 
>  // RUN: FileCheck %s
>  // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n  // CHECK: 
> %[[register("1")]]  // CHECK-SAME: %[[register("2")]] 
// CHECK:
> %[[register("1")]]  // CHECK-SAME: %[[register("2")]]
> %r1 %r2
> %reg1 %reg2 #will fail here.
> 
> 
> If true, I find this confusing, if not, I missed something in your example.
> 
> —
> Mehdi
> 
> 
> 
>> 
>> I saw "something like" because we haven't decided on the
syntax for
>> defining and using patterns (that's what this thread is for). 
>> Briefly, here's the syntax I'd like to use:
>> 
>>  // Defining patterns.
>>  CHECK-DEFINE-PATERN: <Name>(<Ident>, ...)?:
<Pattern>
>> 
>>  Where <Pattern> is a list of <PatternElement>, and a 
>> <PatternElement> is  either a regex ('{{' POSIX_REGEX
'}}') or an argument identifier (IDENT).
>> 
>>  // Using patterns.
>>  CHECK: [[<Name>(<Argument>, ...)?]]
>> 
>> Fleshing this out some more, here is my candidate grammar (see the 
>> end of this email for the current grammar):
>> 
>>  ACTION <- CHECK ':' MATCH '\n' ;
>>  ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST?
':'
>> PATTERN_ELEMENT* '\n' ;  PARAMLIST <- '(' IDENT
(',' IDENT)* ')' ;
>> PATTERN_ELEMENT <- IDENT ;  PATTERN_ELEMENT <- REGEX ;  MATCH
<- ;
>> MATCH <- TEXT MATCH ;  MATCH <- REGEX MATCH ;  MATCH <- VAR
MATCH ;
>> REGEX <- '{{' POSIX_REGEX '}}' ;  VAR <-
'[[' IDENT ':' POSIX_REGEX
>> ']]' ;  VAR <- '[[' IDENT ARGLIST? ']]' ; 
ARGLIST <- '(' ARG (','
>> ARG)* ')' ;  ARG <- "([^"]|\\")*" ;
>> 
>> 
>>> 3. FileCheck Enhancement - repeats in regular expressions 
>>> (https://reviews.llvm.org/D22454), FileCheck Enhancement -
Including files (https://reviews.llvm.org/D22500), FileCheck Enhancement -
Expressions repeat for CHECK and CHECK-NEXT(https://reviews.llvm.org/D22501),
FileCheck Enhancement - CHECK-LABEL-DAG(https://reviews.llvm.org/D22502),
FileCheck Enhancement - prefixes-regular expressions
(https://reviews.llvm.org/D22503) There were no comments about these
enhancements at all. Your opinions are very important.
>> 
>> I personally am waiting for some version of D22403 to land in-tree 
>> before starting on the other reviews. This would help me gauge what 
>> others in the community are thinking and what they need.
>> 
>>> 
>>> I hope that some of these changes will be useful for FileCheck
users, so I need your opinions to get opportunity for review to be resumed.
>> 
>> thanks,
>> vedant
>> 
>> Original FileCheck grammar (shamelessly copied from the grammar 
>> Adrian posted to D22403):
>> 
>>  ACTION <- CHECK ':' MATCH '\n' ;
>>  MATCH <- ;
>>  MATCH <- TEXT MATCH ;
>>  MATCH <- REGEX MATCH ;
>>  MATCH <- VAR MATCH ;
>>  REGEX <- '{{' POSIX_REGEX '}}' ;
>>  VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ; 
VAR <- '[[' IDENT ']]' ;
>> 
>> 
>>> 
>>> -----Original Message-----
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
>>> Elena Lepilkina via llvm-dev
>>> Sent: Wednesday, July 20, 2016 4:52 PM
>>> To: vsk at apple.com
>>> Cc: llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>> 
>>> List of last patches:
>>> 
>>> 1. FileCheck Enhancement - CHECK-WORD (llvm-commits was added later
as diff update) - https://reviews.llvm.org/D22353 2. FileCheck Enhancement -
pattern templates(llvm-commits was added later as diff update) -
https://reviews.llvm.org/D22403 3. FileCheck Enhancement - repeats in regular
expressions (new review with llvm-commits) - https://reviews.llvm.org/D22454 4.
FileCheck Enhancement - Including files (new review with llvm-commits) -
https://reviews.llvm.org/D22500
>>> 5. FileCheck Enhancement - Expressions repeat for CHECK and
CHECK-NEXT (new review with llvm-commits)   - https://reviews.llvm.org/D22501
>>> 6. FileCheck Enhancement - CHECK-LABEL-DAG (new review with 
>>> llvm-commits)  - https://reviews.llvm.org/D22502 7. FileCheck 
>>> Enhancement - prefixes-regular expressions (new review with 
>>> llvm-commits) - https://reviews.llvm.org/D22503
>>> 
>>> Thanks,
>>> Elena.
>>> 
>>> -----Original Message-----
>>> From: vsk at apple.com [mailto:vsk at apple.com]
>>> Sent: Tuesday, July 19, 2016 8:42 PM
>>> To: Elena Lepilkina <Elena.Lepilkina at synopsys.com>
>>> Cc: Dean Michael Berris <dean.berris at gmail.com>; Mehdi
Amini
>>> <mehdi.amini at apple.com>; llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>> 
>>> Hi Elena,
>>> 
>>> 
>>>> On Jul 19, 2016, at 6:36 AM, Elena Lepilkina via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I made new patches for most of changes with llvm-commits
subscriber. But two patches were updated, because there are a lot of comments
(patch for CHECK-WORD and patch for templates pattern). Will it be ok?
>>> 
>>> IMO it's fine to keep some of the original reviews if you
don't want to discard/recreate their state.
>>> 
>>> Please list the most up-to-date set of Phab URL's here, with a
little note next to the ones which did not initially CC llvm-commits.
>>> 
>>> Thanks again for working on this!
>>> 
>>> vedant
>>> 
>>>> 
>>>> Thanks, Elena.
>>>> 
>>>> -----Original Message-----
>>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf
>>>> Of Dean Michael Berris via llvm-dev
>>>> Sent: Tuesday, July 19, 2016 6:53 AM
>>>> To: Mehdi Amini <mehdi.amini at apple.com>
>>>> Cc: via llvm-dev <llvm-dev at lists.llvm.org>
>>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
>>>> 
>>>> 
>>>>> On 19 Jul 2016, at 04:18, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>>> 
>>>>> We had a long thread about that a few weeks (months?) ago:
the conclusion (as I remember) was roughly a guideline to “always start a new
revision to have a proper mailing-list thread starting with context (i.e. patch
description)”
>>>>> (and my dissident minority opinion that it is only worth it
if
>>>>> there hasn’t been significant round of reviews going on on
the
>>>>> existing
>>>>> revision)
>>>>> 
>>>> 
>>>> Pardon me for missing that discussion, this may have already
been asked before: but is it possible to make arcanist default subscribe the
correct commits mailing list in the process? This should make it at least harder
to forget.
>>>> 
>>>> Cheers
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi,

I also like proposed grammar. One minor correction, I guess you want to
allow pattern use with parameters as well:

 PATTERN_USE <- '[[' '@' IDENT ARGLIST? ']]' ;

On Wed, Aug 31, 2016 at 10:56 PM, Vedant Kumar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > At first I thought that `register(n)` was some sort of macro, but if
it
> is suppose to be equivalent to the example above of what we do “today”,
> then using “register(“1”)” is supposed to “capture” the ‘r’ part of the
> register on the first match.
>
>
> This is a problem with my suggested gramamr (specifically: it doesn't
> provide a
> way to use defined patterns to capture text for later reference).  Fred
> brought
> up that he was confused by this too.
>
> One way to fix it is to use '@' before using patterns. I'll
recap the
> suggested
> grammar and work through another example. Here's how you'd define a
> pattern:
>
>   CHECK-DEFINE-PATTERN: car(make, model, year): {{Found a }} make model
> {{, from }} year
>
> And here's how you'd use it, *without* capturing the text into a
variable:
>
>   CHECK: [[@car("Honda", "Accord", "2009")]]
>
> (Note, this matches the text: "Found a Honda Accord, from 2009".)
>
> To use a pattern and capture the matched text in "MY_CAR",
you'd write:
>
>   CHECK: [[MY_CAR @car("Honda", "Accord",
"2009")]]
>
> This gives us an unambiguous way to capture text matched via a defined
> pattern,
> which is visually distinct from how normal regex-based capturing works.
>
> Note that subsequent uses of "MY_CAR" should work as expected
(i.e, you
> can do
> '[[MY_CAR]]' later in the test).
>
> Revised grammar:
>
>    ACTION <- CHECK ':' MATCH '\n' ;
>    ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST?
':'
> PATTERN_ELEMENT* '\n' ;
>    PARAMLIST <- '(' IDENT (',' IDENT)* ')' ;
>    PATTERN_ELEMENT <- IDENT | REGEX;
>    MATCH <- (TEXT | REGEX | PATTERN_USE | VAR)* ;
>    REGEX <- '{{' POSIX_REGEX '}}' ;
>    PATTERN_USE <- '[[' '@' IDENT ']]' ;
>    VAR <- '[[' IDENT ':' POSIX_REGEX ']]' ;
>    VAR <- '[[' IDENT '@' IDENT ARGLIST? ']]' ;
>    ARGLIST <- '(' ARG (',' ARG)* ')' ;
>    ARG <- "([^"]|\\")*" ;
>
> vedant
>
> > On Aug 31, 2016, at 9:11 AM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
> >
> >>
> >> On Aug 24, 2016, at 4:46 PM, Vedant Kumar via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >>>
> >>> On Aug 24, 2016, at 2:04 AM, Elena Lepilkina <
> Elena.Lepilkina at synopsys.com> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> Some discussions and comments were made in reviews. Much time
has
> already passed since last comment and uploading changed patches. I made
> small summary report about features here, because there are some doubts
> about syntax of some features and changes in patches and it'll be great
to
> know more opinions.
> >>>
> >>> 1. FileCheck Enhancement - CHECK-WORD
(https://reviews.llvm.org/D22353
> )
> >>> I replace special directives by flag --check-word, which turns
on mode
> for each directive in file.  It's obvious that this mode can be
replaced
> using \b assert, but current regexp library doesn't have support of
this
> assert and I have no answer to question about possibility of change current
> library.
> >>> There was the discussion about that such mode can be made
default, but
> there were doubts about necessity of a lot of work for changing existing
> tests.
> >>> And I made experiment which proves that a lot of old tests
will be
> failed with such mode on.
> >>> Expected Passes    : 15810
> >>> Expected Failures  : 125
> >>> Unsupported Tests  : 195
> >>> Unexpected Passes  : 4
> >>> Unexpected Failures: 1128
> >>
> >> I would rather not introduce churn in our tests by turning on
> --check-word by
> >> default. I'm also not convinced that turning on --check-word
at the
> test level
> >> is the right move: having a CHECK-WORD directive is more flexible,
and
> not a
> >> serious inconvenience (as compared to writing "CHECK").
> >>
> >>
> >>>
> >>> 2. FileCheck Enhancement - pattern templates (
> https://reviews.llvm.org/D22403)
> >>> There are some doubts about syntax of templates. I agree that
use of
> \#, \:, \= is quite different from usual characters in FileCheck and was
> chosen because of same approach for escaping in regexp. Adrian Prantl
> suggested to use double-brackets "[[" to escape.
> >>> Old syntax:
> >>> \#(template_name) - use of template 'template_name'.
It can occur in
> CHECK-PATTERN line, when description of one template includes other
> templates described before. (Without quote, I don't know how escape #
here)
> >>> \:(Variable_name)- template variable with name
'variable_name'
> >>> \:(variable_name)\=(value) - current value of template
variable(it's
> needed when you use template with variables).
> >>> Suggested new syntax:
> >>> [[#template_name]] - use of template 'template_name'.
It can occur in
> CHECK-PATTERN line, when description of one template includes other
> templates described before. (Without quote, I don't know how escape #
here)
> >>> [[:Variable_name]] - template variable with name
'variable_name'
> >>> [[:variable_name=value]] - current value of template
variable(it's
> needed when you use template with variables).
> >>> It'll be great to hear more opinions and suggestions about
syntax. May
> be someone has really good ideas. Then I'll be able to change it.
> >>
> >> First, I want to recap the FileCheck workflow Elena is proposing:
> >>
> >>  1. Define patterns using the CHECK-DEFINE-PATTERN directive.
Defined
> patterns
> >>     have a name and may optionally have parameters.
> >>
> >>  2. Use defined patterns in the usual CHECK* directives.
> >>
> >> This is similar to how FileCheck patterns work already. The
difference
> is
> >> that the patterns are defined using a dedicated directive, *not*
when
> the
> >> pattern is first encountered. E.g, here is what you can do today:
> >>
> >>  // RUN: echo "%r1 %r2" | FileCheck %s
> >>  // CHECK: %[[register:[a-z]+]]1
> >>  // CHECK-SAME: %[[register]]2
> >>
> >> With the proposed changes, we'll be able to write something
like:
> >>
> >>  // RUN: echo "%cmp %cmp" | FileCheck %s
> >>  // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
> >>  // CHECK: %[[register("1")]]
> >>  // CHECK-SAME: %[[register("2")]]
> >
> > At first I thought that `register(n)` was some sort of macro, but if
it
> is suppose to be equivalent to the example above of what we do “today”,
> then using “register(“1”)” is supposed to “capture” the ‘r’ part of the
> register on the first match.
> > So you cannot reuse “register()” later to capture another expression.
> For instance:
> >
> >  // RUN: FileCheck %s
> >  // CHECK-DEFINE-PATERN: register(n): {{[a-z]+}}n
> >  // CHECK: %[[register("1")]]
> >  // CHECK-SAME: %[[register("2")]]
> >  // CHECK: %[[register("1")]]
> >  // CHECK-SAME: %[[register("2")]]
> > %r1 %r2
> > %reg1 %reg2 #will fail here.
> >
> >
> > If true, I find this confusing, if not, I missed something in your
> example.
> >
> > —
> > Mehdi
> >
> >
> >
> >>
> >> I saw "something like" because we haven't decided on
the syntax for
> defining
> >> and using patterns (that's what this thread is for). Briefly,
here's
> the syntax
> >> I'd like to use:
> >>
> >>  // Defining patterns.
> >>  CHECK-DEFINE-PATERN: <Name>(<Ident>, ...)?:
<Pattern>
> >>
> >>  Where <Pattern> is a list of <PatternElement>, and a
<PatternElement>
> is
> >>  either a regex ('{{' POSIX_REGEX '}}') or an
argument identifier
> (IDENT).
> >>
> >>  // Using patterns.
> >>  CHECK: [[<Name>(<Argument>, ...)?]]
> >>
> >> Fleshing this out some more, here is my candidate grammar (see the
end
> of this
> >> email for the current grammar):
> >>
> >>  ACTION <- CHECK ':' MATCH '\n' ;
> >>  ACTION <- CHECK-DEFINE-PATTERN ':' IDENT PARAMLIST?
':'
> PATTERN_ELEMENT* '\n' ;
> >>  PARAMLIST <- '(' IDENT (',' IDENT)*
')' ;
> >>  PATTERN_ELEMENT <- IDENT ;
> >>  PATTERN_ELEMENT <- REGEX ;
> >>  MATCH <- ;
> >>  MATCH <- TEXT MATCH ;
> >>  MATCH <- REGEX MATCH ;
> >>  MATCH <- VAR MATCH ;
> >>  REGEX <- '{{' POSIX_REGEX '}}' ;
> >>  VAR <- '[[' IDENT ':' POSIX_REGEX ']]'
;
> >>  VAR <- '[[' IDENT ARGLIST? ']]' ;
> >>  ARGLIST <- '(' ARG (',' ARG)* ')' ;
> >>  ARG <- "([^"]|\\")*" ;
> >>
> >>
> >>> 3. FileCheck Enhancement - repeats in regular expressions (
> https://reviews.llvm.org/D22454), FileCheck Enhancement - Including files
> (https://reviews.llvm.org/D22500), FileCheck Enhancement - Expressions
> repeat for CHECK and CHECK-NEXT(https://reviews.llvm.org/D22501),
> FileCheck Enhancement - CHECK-LABEL-DAG(https://reviews.llvm.org/D22502),
> FileCheck Enhancement - prefixes-regular expressions (
> https://reviews.llvm.org/D22503)
> >>> There were no comments about these enhancements at all. Your
opinions
> are very important.
> >>
> >> I personally am waiting for some version of D22403 to land in-tree
> before
> >> starting on the other reviews. This would help me gauge what
others in
> the
> >> community are thinking and what they need.
> >>
> >>>
> >>> I hope that some of these changes will be useful for FileCheck
users,
> so I need your opinions to get opportunity for review to be resumed.
> >>
> >> thanks,
> >> vedant
> >>
> >> Original FileCheck grammar (shamelessly copied from the grammar
Adrian
> posted
> >> to D22403):
> >>
> >>  ACTION <- CHECK ':' MATCH '\n' ;
> >>  MATCH <- ;
> >>  MATCH <- TEXT MATCH ;
> >>  MATCH <- REGEX MATCH ;
> >>  MATCH <- VAR MATCH ;
> >>  REGEX <- '{{' POSIX_REGEX '}}' ;
> >>  VAR <- '[[' IDENT ':' POSIX_REGEX ']]'
;
> >>  VAR <- '[[' IDENT ']]' ;
> >>
> >>
> >>>
> >>> -----Original Message-----
> >>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
> Elena Lepilkina via llvm-dev
> >>> Sent: Wednesday, July 20, 2016 4:52 PM
> >>> To: vsk at apple.com
> >>> Cc: llvm-dev at lists.llvm.org
> >>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
> >>>
> >>> List of last patches:
> >>>
> >>> 1. FileCheck Enhancement - CHECK-WORD (llvm-commits was added
later as
> diff update) - https://reviews.llvm.org/D22353 2. FileCheck Enhancement -
> pattern templates(llvm-commits was added later as diff update) -
> https://reviews.llvm.org/D22403 3. FileCheck Enhancement - repeats in
> regular expressions (new review with llvm-commits) -
> https://reviews.llvm.org/D22454 4. FileCheck Enhancement - Including
> files (new review with llvm-commits) - https://reviews.llvm.org/D22500
> >>> 5. FileCheck Enhancement - Expressions repeat for CHECK and
CHECK-NEXT
> (new review with llvm-commits)   - https://reviews.llvm.org/D22501
> >>> 6. FileCheck Enhancement - CHECK-LABEL-DAG (new review with
> llvm-commits)  - https://reviews.llvm.org/D22502 7. FileCheck Enhancement
> - prefixes-regular expressions (new review with llvm-commits) -
> https://reviews.llvm.org/D22503
> >>>
> >>> Thanks,
> >>> Elena.
> >>>
> >>> -----Original Message-----
> >>> From: vsk at apple.com [mailto:vsk at apple.com]
> >>> Sent: Tuesday, July 19, 2016 8:42 PM
> >>> To: Elena Lepilkina <Elena.Lepilkina at synopsys.com>
> >>> Cc: Dean Michael Berris <dean.berris at gmail.com>;
Mehdi Amini <
> mehdi.amini at apple.com>; llvm-dev at lists.llvm.org
> >>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
> >>>
> >>> Hi Elena,
> >>>
> >>>
> >>>> On Jul 19, 2016, at 6:36 AM, Elena Lepilkina via llvm-dev
<
> llvm-dev at lists.llvm.org> wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I made new patches for most of changes with llvm-commits
subscriber.
> But two patches were updated, because there are a lot of comments (patch
> for CHECK-WORD and patch for templates pattern). Will it be ok?
> >>>
> >>> IMO it's fine to keep some of the original reviews if you
don't want
> to discard/recreate their state.
> >>>
> >>> Please list the most up-to-date set of Phab URL's here,
with a little
> note next to the ones which did not initially CC llvm-commits.
> >>>
> >>> Thanks again for working on this!
> >>>
> >>> vedant
> >>>
> >>>>
> >>>> Thanks, Elena.
> >>>>
> >>>> -----Original Message-----
> >>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org]
On Behalf Of
> >>>> Dean Michael Berris via llvm-dev
> >>>> Sent: Tuesday, July 19, 2016 6:53 AM
> >>>> To: Mehdi Amini <mehdi.amini at apple.com>
> >>>> Cc: via llvm-dev <llvm-dev at lists.llvm.org>
> >>>> Subject: Re: [llvm-dev] RFC: FileCheck Enhancements
> >>>>
> >>>>
> >>>>> On 19 Jul 2016, at 04:18, Mehdi Amini via llvm-dev
<
> llvm-dev at lists.llvm.org> wrote:
> >>>>>
> >>>>> We had a long thread about that a few weeks (months?)
ago: the
> conclusion (as I remember) was roughly a guideline to “always start a new
> revision to have a proper mailing-list thread starting with context (i.e.
> patch description)”
> >>>>> (and my dissident minority opinion that it is only
worth it if there
> >>>>> hasn’t been significant round of reviews going on on
the existing
> >>>>> revision)
> >>>>>
> >>>>
> >>>> Pardon me for missing that discussion, this may have
already been
> asked before: but is it possible to make arcanist default subscribe the
> correct commits mailing list in the process? This should make it at least
> harder to forget.
> >>>>
> >>>> Cheers
> >>>> _______________________________________________
> >>>> LLVM Developers mailing list
> >>>> llvm-dev at lists.llvm.org
> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>> _______________________________________________
> >>>> LLVM Developers mailing list
> >>>> llvm-dev at lists.llvm.org
> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160902/f8705666/attachment.html>