In D53565#1298612, @homerdin wrote:

I tried out -DTEST_SUITE_SUBDIRS=SingleSource/Benchmarks/Misc. It gets the desired smaller build tree, but ends up missing lit.local.cfg in SingleSouce so the tests fail.

Please, could someone review these changes?
Or may be add other reviewers if I choose wrong people?

In D22501#551507, @alexfh wrote:

This patch brings up a number of questions:

1. What's your use case? Optimizing tests by replacing a known number of check lines with repeated patterns? Or is the number of patterns you expect not known in advance?

Both first and second case.

2. Are there possible usages of this feature in LLVM tests already?

I don't know LLVM tests well to answer this question.

3. How is this going to interact with [[@LINE]]?

I used FileCheck Match function in loop, so it will be real LINE value. I don't change matching.

There is problem with STL, their realization of regular expressions doesn't match start and end of line in basic mode and there is no multiline mode. There is the issue 2343 in http://cplusplus.github.io/LWG/lwg-toc.html.
There is opportunity to split text by lines and match each line separately, but I think this is a hack, and I think it'll slow FileCheck.

Ok, I'll try to use STL regex.

Patch without modifiers for pattern parameters and using pattern and variables inside definition of other patterns.

As I understood most of users prefer to change library to have support of \b assert. But, I think, this decision is quite important and can be made only by he contributor of FileCheck. I don't know how this suggestion can be done. Or I can try to change library and create a patch with this changes?

What are our options with the regex library? Is there a newer version of the one we are currently using that we could upgrade to (and that supports \b)?

Are quotes necessary for parameters? Everything is string in FileCheck.
Using patterns and variables was in old grammer. I thought that we only change syntax, so I added this feature too.
Ok, I'll remove this from this patch. But then I want to add using patterns and variables in definitions later. On my opinion these features are quite useful.

Change syntax to new one suggested by Vedant Kumar.

In D22353#535691, @alexfh wrote:

Why not add more words to check lines to make them more strict? BTW, does FileCheck support {{\b}}?

In D22403#491468, @aprantl wrote:

They are also both placeholders for a pattern. Can you give an example where it is useful to tell the difference between a use of a pattern and a use of a plain old variable? Does it make the test more readable?
I'm not saying that we have to share the syntax, but adding more syntax increases the cognitive load on testcase authors and we should make sure we are doing it for the right reasons.

I made new mode and made experiment turned it on for all LLVM tests.
Result:

Expected Passes    : 15810
Expected Failures  : 125
Unsupported Tests  : 195
Unexpected Passes  : 4
Unexpected Failures: 1128

Replace set of new CHECK directives to new -check-word option

In D22403#489895, @aprantl wrote:

Is there a benefit in (or need for) distinguishing between variable uses and pattern uses, or could we piggyback the existing syntax?

There is difference between patterns and variables so we should understand where variable is, where pattern is.

As for pattern variables, I really think this review would benefit if we could split out pattern variables into a separate review. I didn't yet understand how pattern variables are supposed to work: Is \:(variable)\=(value) supposed to be an argument to a pattern use that immediately precedes it? Or is it modifying global state similar to regular variable definition in FileCheck? If the latter is the case, why does it come after the pattern in the example? In the former case, wouldn't it be better to have syntax that looks more like passing in an argument?

There is a suggestion to add new option, which will change standart behaviour to word-matchinf instead of addding new set of CHECKs directives. What about this idea?

About syntax.
There is an idea to do as you advised.
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).
Is this syntax better? Should I do such way?

In D22403#488644, @aprantl wrote:

Using CHECK-lines to define meta-variables without checking anything diverges from FileCheck's usual behavior.

In D22353#485513, @probinson wrote:

We won't know until somebody tries. It should not be too hard to do the experiment, I've done that kind of thing twice already.

I'll glad if there will be some suggestions how make syntax better. The main idea of this syntax was to use characters with \ for avoiding escaping these characters in standart patterns.

"I think either users should use "\b" to check that the edge of the match is at the beginning/end of a word" - Problem is that current regexp library doesn't support \b assertion. And question about changing library appears again.
I think, if change the meaning of CHECK there will be a lot of work of changing LLVM tests and private tests of FileCheck users.