Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
60,070 ms | x64 debian > MLIR.Examples/standalone::test.toy |
Event Timeline
For clang AST dump test cases, we often have code like
TranslationUnitDecl `-FunctionDecl <line:2:1, line:5:1> line:2:5 func 'int (int, int)' |-ParmVarDecl <col:10, col:14> col:14 used x 'int' |-ParmVarDecl <col:17, col:21> col:21 used y 'int' `-CompoundStmt <col:24, line:5:1> `-ReturnStmt <line:3:5, col:16> `-BinaryOperator <col:12, col:16> 'int' '+' |-ImplicitCastExpr <col:12> 'int' <LValueToRValue> | `-DeclRefExpr <col:12> 'int' lvalue ParmVar 0xbb44db0 'x' 'int' `-ImplicitCastExpr <col:16> 'int' <LValueToRValue> `-DeclRefExpr <col:16> 'int' lvalue ParmVar 0xbb44e30 'y' 'int'
with matching rules like
FunctionDecl {{.*}} func 'int (int, int)'
with --match-full-lines we would need to add the ugly trailing stuff to test cases.
I'm not really seeing from your example why you need --match-full-lines at all. Are you just looking for the {{^}} and {{$}} regex patterns?
--match-full-lines is require to check that nothing trailing is missing. Current approach is to add in 100 lines {{$}}
I also don't see a need to add any new option.
We often check things this way:
# RUN: llvm-readobj --file-headers %t.i386 | FileCheck %s --strict-whitespace --match-full-lines -DFILE=%t.i386 --check-prefix I386
# I386:File: [[FILE]] # I386-NEXT:Format: elf32-i386 # I386-NEXT:Arch: i386 # I386-NEXT:AddressSize: 32bit # I386-NEXT:LoadName: <Not found> # I386-NEXT:ElfHeader { # I386-NEXT: Ident { # I386-NEXT: Magic: (7F 45 4C 46)
Note that : is aligned, different from the style we use when --strict-whitespace --match-full-lines are unused.
Okay, I think I see your point. You are simply looking to find a way to apply that regex pattern to every line, much like --match-full-lines adds an implicit {{^}} and {{$}} around each line. Is that correct? And you don't want to use --match-full-lines because of the noisy prefixes (hence I'm not sure @MaskRay's suggestion will work).
I'm not strongly opposed to the new options. However, they should be a) documented, and b) I think the names are wrong, since they contradict themselves - trailing only means not "full-lines". I would suggest that the names might be --match-leading-lines and --match-trailing-lines or something to that effect.
On one hand, I want to argue this patch will contribute to the difficulty of writing careful FileCheck directives because, when looking at a FileCheck pattern, there would be even more possible strictness levels that might be in effect. I already get confused when moving among tests: sometimes I think I still have the strictness of -match-full-lines or -strict-whitespace as I saw in the last test, but in the test I'm currently editing I don't, so I accidentally write a weak pattern.
On the other hand, this patch might encourage people to make tests more strict. They might not if strictness requires extending hundreds of lines with {{^}}, {{$}}, or {{.*}} (useful when -match-full-lines is already in effect but the start/end of a line is not interesting).
At least the implementation is simple.
However, they should be a) documented,
And tested in FileCheck's own test suite.
and b) I think the names are wrong, since they contradict themselves - trailing only means not "full-lines". I would suggest that the names might be --match-leading-lines and --match-trailing-lines or something to that effect.
Agreed except those names confuse me too. :-) It sounds like matching multiple leading/trailing lines in a file.
Maybe -strict-line-start and -strict-line-end?
llvm/utils/FileCheck/FileCheck.cpp | ||
---|---|---|
94 | For opt-in options, we typically omit cl::init(false) |
Alright, thank you all for your detailed feedback. I'll address all comments and provide an updated patch with documentation, test case and the proposed changes. Unfortunately, I am going on vacating right now and I am not sure if I am in the mood of development. So it could take some weeks ...
For opt-in options, we typically omit cl::init(false)