This is an archive of the discontinued LLVM Phabricator instance.

[FileCheck] Added [[@CLEAR:regex]] as a way to clear variables.
AbandonedPublic

Authored by tra on Mar 7 2017, 4:29 PM.

Details

Reviewers
chandlerc
jlebar
Summary

The patch introduces special variable [[@CLEAR:regex]] which
always matches without consuming any input and undefines all
variables that match supplied regex.

This is useful for keeping individual tests in the same file hermetic.
Currently, it's very easy for a failing test to pass because it
happened to use a variable set by a preceding similar test.

Event Timeline

tra created this revision.Mar 7 2017, 4:29 PM
arsenm added a subscriber: arsenm.Mar 7 2017, 4:33 PM

I always thought that a CHECK-LABEL should clear all defined variables

arsenm added a comment.Mar 7 2017, 4:46 PM

I always thought that a CHECK-LABEL should clear all defined variables

It definitely does not now, I think it would be less burdensome than having to list every used variable (which is just another place you can make a typo) to clear it

tra added a comment.Mar 7 2017, 4:47 PM

I always thought that a CHECK-LABEL should clear all defined variables

As far as I can tell it does not. E.g. this passes:

// RUN: FileCheck -check-prefix Y -input-file %s %s

op y2
op y2l
op y2 y3
; Y:  [[REGY:y[0-9]]]
; Y-LABEL:  op y2l
; Y:  op [[REGY]] y3
jlebar edited edge metadata.Mar 7 2017, 4:50 PM

It definitely does not now, I think it would be less burdensome than having to list every used variable (which is just another place you can make a typo) to clear it

Yeah, but cleaning that up globally in all our tests sounds like a recipe for disaster. And I'm sure we'll also find some tests where we really *do* want to keep regexps alive across CHECK-LABELS.

I suppose we could have a filecheck mode that behaves as you describe, but that also sounds worse.

Also, if you don't want to list the used variables, you can match on [[@CLEAR:.*]].

arsenm added a comment.Mar 7 2017, 4:53 PM

It definitely does not now, I think it would be less burdensome than having to list every used variable (which is just another place you can make a typo) to clear it

Yeah, but cleaning that up globally in all our tests sounds like a recipe for disaster. And I'm sure we'll also find some tests where we really *do* want to keep regexps alive across CHECK-LABELS.

I suppose we could have a filecheck mode that behaves as you describe, but that also sounds worse.

Also, if you don't want to list the used variables, you can match on [[@CLEAR:.*]].

I think those are abuses of CHECK-LABEL then. The use case is to treat a region begun by a label as a separate error reporting region. The common case is for multiple independent testcase functions in a single file. The weird case that is checking matches between functions is a special case that I don't think should be using -LABEL

jlebar added a comment.Mar 7 2017, 4:55 PM

I think those are abuses of CHECK-LABEL then.

I'm not sure I agree, but even if I do, I'm not volunteering to clean them up... That seems like a lot of pain for no gain.

tra added a comment.Mar 7 2017, 5:11 PM

@arsenm

I think check-label and regex variables are orthogonal. CHECK-LABEL does separate chunks of input for matching and error reporting purposes, but regex variables are more akin to a preprocessor -- we use variable value to construct regex to match against the input. I don't think CHECK-LABEL is a good fit for hard boundary on variable lifetime.

Here's one (reasonable, I believe) use case for across-the-CHECK-LABEL vars:

; CHECK-LABEL: generated_function_foo
; CHECK: store something [[SHARED_OBJECT:generated_object_name_x[0-9]+]]
...
; CHECK-LABEL: generated_function_bar
; CHECK: x = load [[SHARED_OBJECT]]
arsenm added a comment.Mar 7 2017, 5:16 PM
In D30725#695129, @tra wrote:

@arsenm

I think check-label and regex variables are orthogonal. CHECK-LABEL does separate chunks of input for matching and error reporting purposes, but regex variables are more akin to a preprocessor -- we use variable value to construct regex to match against the input. I don't think CHECK-LABEL is a good fit for hard boundary on variable lifetime.

Here's one (reasonable, I believe) use case for across-the-CHECK-LABEL vars:

; CHECK-LABEL: generated_function_foo
; CHECK: store something [[SHARED_OBJECT:generated_object_name_x[0-9]+]]
...
; CHECK-LABEL: generated_function_bar
; CHECK: x = load [[SHARED_OBJECT]]

If not CHECK-LABEL, then I think a CLEAR-ALL-VARIABLES would be more helpful/less burdensome than clearing individual vars (or maybe a CHECK-REGION combination of LABEL and clearing)

tra added a comment.Mar 7 2017, 5:37 PM

@arsenm OK. CHECK-REGION (= CHECK-LABEL + clear all vars) would work for me.

Any other opinions?

jlebar added a comment.Mar 7 2017, 5:44 PM

I like CHECK-REGION.

hfinkel added a subscriber: hfinkel.Mar 7 2017, 5:44 PM
In D30725#695171, @tra wrote:

@arsenm OK. CHECK-REGION (= CHECK-LABEL + clear all vars) would work for me.

Any other opinions?

What if we divided the regex names into two classes: local and global. CHECK-LABEL cleared the local ones and the global ones stayed around? We could do something like have:

[[@NAME:[pattern]]]

bind a global name (and the existing ones without the @ are local).

tra added a comment.Mar 7 2017, 5:52 PM

@hfinkel I like the global/local split. @ would clash with @LINE[-+]N expression we currently support, but we could use some other prefix instead. $ ?

In D30725#695187, @tra wrote:

@hfinkel I like the global/local split. @ would clash with @LINE[-+]N expression we currently support, but we could use some other prefix instead. $ ?

$ is certainly fine with me.