similar to: FileCheck: using numeric variable defined on same line with caveats

Before addressing the CHECK-NOT case, I’m still unclear about the DAG case. What should the first DAG line match? The regex matching would first attempt to match “10 12” but the expression evaluation would fail; so the DAG candidate wouldn’t match; does this mean the DAG matching does not continue searching, and the test fails? Or would we restart the search…. where? With “0 12” (skipping only

Any kind of variable definition on a CHECK-NOT line would seem like it would be asking for trouble. Do we allow text variable definitions on a NOT? False fails are better than false matches. Given that it will fail on a line where you'd expect a match, or possibly for the line to be skipped, it's a matter of refining the match expression, which is something that you have to do sometimes

Thanks for the suggestions. I think the naming the whole line idea is okay, but it feels a bit clunky. Either we'd have to have a syntax that FileCheck would recognise without caring about the prefix (which seems to be against the ethos of FileCheck, and also makes it less flexible), or in the case I'm referring to, we'd have to have an extra line that does nothing other than define

​Hi all, > I feel it might be confusing to have a CHECK becomes effectively a CHECK-NOT, > especially if the RUN line is far from the CHECK line (which is often the case when > a single RUN line drives several groups of CHECK directives (e.g. code generation > tested for several functions for a specific feature, like PIC). You also loose control > on where the NOT should be:

Hi, I'm looking for some feedback on pain points people have with FileCheck in terms of missing features to help people interested in working on FileCheck to prioritize the work accordingly. I am personally interested in improving FileCheck on 2 issues whenever time permits it: * being able to test for consecutive lines in arbitrary order, i.e. something akin to CHECK-DAG blocks where

Hi all, There have been a few cases recently where I've noticed two test cases in the same lit test that do the same thing except invert the CHECK, to show that something is NOT present. I'm talking about something like the following: # RUN: llvm-sometool --print-string | FileCheck %s --check-prefix=STRING # RUN: llvm-sometool --no-print-string | FileCheck %s --check-prefix=NO-STRING #

On 05/24/2018 08:46 AM, via llvm-dev wrote: > Background > ---------- > > FileCheck [0] is a cornerstone testing tool for the LLVM project. It > has grown new features over the years to meet new needs, but these > sometimes have surprising and counter-intuitive behavior [1]. This > has become even more evident in Joel Denny's recent quest to repair > what seemed like

Hi all, Many of our lit tests use FileCheck and a tool like llvm-readobj to check properties of a section header/symbol/etc. A typical (pseudoised for brevity) output to match against might be something like the following: Symbols [ Symbol { Name: foo Value: 0 Type: Function Section: .foo (1) } Symbol { Name: bar Value: 1 Type: Object Section: .foo (1) } ]

Hi Jessica, This time I'm replying all.... On Fri, May 4, 2018 at 12:45 PM, Jessica Paquette <jpaquette at apple.com> wrote: > I would personally like a feature like that in FileCheck because it would > make it a lot easier to write MachineOutliner tests, and would make the > tests significantly smaller and easier to understand. > How do MachineOutliner tests accomplish

I would personally like a feature like that in FileCheck because it would make it a lot easier to write MachineOutliner tests, and would make the tests significantly smaller and easier to understand. - Jessica > On May 4, 2018, at 8:40 AM, Joel E. Denny via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > Using FileCheck, I have not found a way to make a group of

Right now, the tests try to accomplish the following 1. Define a sequence of instructions (e.g a,b,c) 2. Insert that sequence into k places with an unique instruction between them to make sure the outliner will yank them out *without overlaps* 3. Check for k calls to an outlined function 4. Check that the outlined sequence still exists in the program This can result in some pretty long tests

Hi, Using FileCheck, I have not found a way to make a group of CHECK-DAG directives match multiple occurrences of a string. For example, I naively thought the following would match successfully: ``` $ cat checks.txt // CHECK: start // CHECK-DAG: foo // CHECK-DAG: foo // CHECK-DAG: bar // CHECK-NEXT: end $ cat input.txt start foo bar foo end $ FileCheck --input-file=input.txt checks.txt

Hi Paul, On Thu, May 24, 2018 at 9:46 AM, <paul.robinson at sony.com> wrote: > Background > ---------- > > FileCheck [0] is a cornerstone testing tool for the LLVM project. It > has grown new features over the years to meet new needs, but these > sometimes have surprising and counter-intuitive behavior [1]. This > has become even more evident in Joel Denny's

Background ---------- FileCheck [0] is a cornerstone testing tool for the LLVM project. It has grown new features over the years to meet new needs, but these sometimes have surprising and counter-intuitive behavior [1]. This has become even more evident in Joel Denny's recent quest to repair what seemed like an obvious defect [2] but which led me to the conclusion [3] that FileCheck sorely

A few replies, then I'll post a revised spec v2 which ought to incorporate all the other feedback. If I missed something, give a shout. Actually, I wish there were a way to do that [constrain DAG to a single line] for the sake of matching unordered text on a single line. SAME after DAGs is as close as I can get to that. Maybe we need a CHECK-DAG-SAME. Hmmm. You know, there were cases

Thanks Joel and Chris, comments inline. >> CHECK: Scans the search range for a pattern match. Fails if no match >> is found.  The end of the match range becomes the start of the search >> range for subsequent directives. >> >> CHECK-SAME: Like CHECK, plus there must be zero newlines prior to the >> start of the match range. > > ... within the search

> 1. In a CHECK-DAG group, don't let the matches for patterns overlap. > 2. Add a new CHECK-DAG-N directive, where N is some integer, to express > that a pattern must have N non-overlapping matches. I think #1 is much more intuitive and easy to describe/document than #2. Changing the meaning of DAG in that way is highly unlikely to affect any existing test, IMO. And if it does, my

I just stumbled across r332416, which was modifying a test with multiple identical CHECK-DAG directives, which reminded me I needed to get back to you about this... sorry for the slow response. > From: Joel E. Denny [mailto:jdenny.ornl at gmail.com] >> On Mon, May 7, 2018 at 12:56 PM, <paul.robinson at sony.com> wrote: >>> 1. In a CHECK-DAG group, don't let the matches

Hi, CHECK-WORD - If you want find some string in file, but you want to be sure, that this string should be a separate word. There are examples in file. Prefixes which can be described as regular expressions should be turning on with option -regex-prefixes . By default, you can't use it. Thanks for your comments. -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at

On Mon, May 7, 2018 at 12:56 PM, <paul.robinson at sony.com> wrote: > > 1. In a CHECK-DAG group, don't let the matches for patterns overlap. > > 2. Add a new CHECK-DAG-N directive, where N is some integer, to express > > that a pattern must have N non-overlapping matches. > > I think #1 is much more intuitive and easy to describe/document than #2. > Changing