[llvm-dev] FileCheck idiom difficulties

Wed Nov 6 08:41:53 PST 2019

I keep forgetting about CHECK-LABEL, thanks! In many cases, the name lines
are unique, so this would probably work, although with sections, for
example, they don't have to be (but in 99% of tests they can be). I think
in the limited cases where CHECK-LABEL isn't possible, we can use one of
the uglier syntaxes.

On Wed, 6 Nov 2019 at 13:54, Thomas Preud'homme <thomasp at graphcore.ai>
wrote:

> Aren't the name lines unique? If they are you could use the good old
> CHECK-LABEL:
>
> # CHECK-LABEL: Name: foo
> # CHECK: Section: .foo (1)
> ------------------------------
> *From:* George Rimar <grimar at accesssoftek.com>
> *Sent:* 06 November 2019 13:01
> *To:* jh7370.2008 at my.bristol.ac.uk <jh7370.2008 at my.bristol.ac.uk>
> *Cc:* Fāng-ruì Sòng <maskray at google.com>; llvm-dev <
> llvm-dev at lists.llvm.org>; Thomas Preud'homme <thomasp at graphcore.ai>; Paul
> Robinson <paul.robinson at sony.com>
> *Subject:* Re: FileCheck idiom difficulties
>
>
> > One idea I had was for a new directive something like "CHECK-IMMEDIATE"
> which
>
> > is implicitly the same as the final approach I suggested above, but
> maybe adding a new
>
> > directive to achieve this isn't the right approach?
>
>
> "CHECK-IMMEDIATE" (or "CHECK-CONTINUE"/better name) sound like a clean
> and fine approach to me.
>
> I'd go with it probably.
>
>
> Best regards,
> George | Developer | Access Softek, Inc
> ------------------------------
> *От:* James Henderson <jh7370.2008 at my.bristol.ac.uk>
> *Отправлено:* 6 ноября 2019 г. 15:17
> *Кому:* llvm-dev; George Rimar; Fāng-ruì Sòng; Paul Robinson;
> thomasp at graphcore.ai
> *Тема:* FileCheck idiom difficulties
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.  If you suspect potential phishing or spam email,
> report it to ReportSpam at accesssoftek.com
>
> 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)
>   }
> ]
>
> and your lit test might want to check the properties of the foo symbol
> like so:
>
> # CHECK:      Name: foo
> # CHECK-NEXT: Value: 0
> # CHECK-NEXT: Type: Function
> # CHECK-NEXT: Section: .foo (1)
>
> This is fine. But what if you only care about the section of a symbol, and
> not the value or type etc? You could do the following:
>
> # CHECK: Name: foo
> # CHECK: Section: .foo (1)
>
> Hopefully some of you will already notice the problem with this approach:
> if foo was in, say, the .baz section, the test will spuriously pass,
> because the Section line will match the Section line for .bar. One
> alternative to this is to explicitly match each field in between, using
> CHECK-NEXT:
>
> # CHECK:      Name: foo
> # CHECK-NEXT: Value:
> # CHECK-NEXT: Type:
> # CHECK-NEXT: Section: .foo (1)
>
> This works, but somewhat hides what is really being tested by adding extra
> noise to the checks. In reality, there are actually other fields too that
> need to be listed, meaning the "interesting" parts of the test are even
> more hidden.
>
> I recently started using yet another approach:
>
> # CHECK: Name: foo
> # CHECK: Section:
> # CHECK-SAME:     .foo (1)
>
> This works because the Section: matched will be the first one found, i.e.
> the one belonging to foo, and then .foo will be looked for on the same
> line. However, I noticed today that this pattern has its own problem,
> namely that there could be something between the Section tag and .foo. In
> other words, the above pattern would match "Section: .bar.foo". A couple of
> solutions to this are:
>
> # CHECK: Section:
> # CHECK-NOT: {{[:graph:]}}
> # CHECK-SAME: .foo (1)
>
> # CHECK: Section:
> # CHECK-SAME: {{^}} .foo (1)
>
> The first one ensures that there's no non-whitespace between the end of
> "Section:" and the start of ".foo (1)". The second ensures that the start
> of the CHECK-SAME match is the "start of line", and since the first half of
> the line has already been consumed, it means " .foo (1)" must immediately
> follow "Section:". However, the first is even less readable than the
> current CHECK-SAME approach, whilst the second is somewhat confusing if you
> don't realise that FileCheck effectively consumes the things it has matched
> already, so that they effectively don't exist any more.
>
> Does anybody have any other suggestions/thoughts/comments? One idea I had
> was for a new directive something like "CHECK-IMMEDIATE" which is
> implicitly the same as the final approach I suggested above, but maybe
> adding a new directive to achieve this isn't the right approach?
>
> James
>
>
> ** We have updated our privacy policy, which contains important
> information about how we collect and process your personal data. To read
> the policy, please click here <http://www.graphcore.ai/privacy> **
>
> This email and its attachments are intended solely for the addressed
> recipients and may contain confidential or legally privileged information.
> If you are not the intended recipient you must not copy, distribute or
> disseminate this email in any way; to do so may be unlawful.
>
> Any personal data/special category personal data herein are processed in
> accordance with UK data protection legislation.
> All associated feasible security measures are in place. Further details
> are available from the Privacy Notice on the website and/or from the
> Company.
>
> Graphcore Limited (registered in England and Wales with registration
> number 10185006) is registered at 107 Cheapside, London, UK, EC2V 6DN.
> This message was scanned for viruses upon transmission. However Graphcore
> accepts no liability for any such transmission.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191106/5b84111b/attachment.html>