Proposed new policy for tests which are looking at the output of -ast-dump

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed new policy for tests which are looking at the output of -ast-dump

Vassil Vassilev via cfe-dev
Hi all!

I would like to propose a new policy for tests which are looking at
the output of -ast-dump:

Any such test must also look at the output of -ast-dump-all after
deserialization, or explain why an exception is needed.

Modulo a few differences (the "<undeserialized declarations>"s and the "imported"s)
the outputs should match. This has already helped to find and fix two serialization
bugs (one in LambdaExpr fixed in 05843dc6ab97a00cbde7aa4f08bf3692eb83109d, and one
in ConstantExpr, fixed in e7ce0528202306d8b751f132d9d3a6519ce4e688).

How:

1) For hand-written tests, strip the "<undeserialized declarations>"s and the
   "imported"s with sed. For example if the original RUN line is

   // RUN: %clang_cc1 -ffoo -fbar -ast-dump -ast-dump-filter Whatever %s \
   // RUN: | FileCheck %s --strict-whitespace

   then add the following RUN lines:

   // RUN: %clang_cc1 -ffoo -fbar -emit-pch -o %t %s
   // RUN: %clang_cc1 -x c++ -ffoo -fbar -include-pch %t -ast-dump-all -ast-dump-filter Whatever /dev/null \
   // RUN: | sed -e "s/ <undeserialized declarations>//" -e "s/ imported//" \
   // RUN: | FileCheck %s --strict-whitespace

2) For tests autogenerated with make-ast-dump-check.sh, generate the test with the
   recently added option "generate_serialization_test=1".

This will of course not find every serialization bugs. However given the tiny additional
cost (a few RUN lines), I don't see any downsides.

Thanks!

Bruno Ricci
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new policy for tests which are looking at the output of -ast-dump

Vassil Vassilev via cfe-dev
+1, i support this.

If we won't do that in an organized matter, I suspect, we will be
hitting every one of these bugs sooner or later with/via modules.

Thanks for looking into improving [de]serialization quality!

Roman.

On Sun, Jun 21, 2020 at 5:20 PM Bruno Ricci via cfe-dev
<[hidden email]> wrote:

>
> Hi all!
>
> I would like to propose a new policy for tests which are looking at
> the output of -ast-dump:
>
> Any such test must also look at the output of -ast-dump-all after
> deserialization, or explain why an exception is needed.
>
> Modulo a few differences (the "<undeserialized declarations>"s and the "imported"s)
> the outputs should match. This has already helped to find and fix two serialization
> bugs (one in LambdaExpr fixed in 05843dc6ab97a00cbde7aa4f08bf3692eb83109d, and one
> in ConstantExpr, fixed in e7ce0528202306d8b751f132d9d3a6519ce4e688).
>
> How:
>
> 1) For hand-written tests, strip the "<undeserialized declarations>"s and the
>    "imported"s with sed. For example if the original RUN line is
>
>    // RUN: %clang_cc1 -ffoo -fbar -ast-dump -ast-dump-filter Whatever %s \
>    // RUN: | FileCheck %s --strict-whitespace
>
>    then add the following RUN lines:
>
>    // RUN: %clang_cc1 -ffoo -fbar -emit-pch -o %t %s
>    // RUN: %clang_cc1 -x c++ -ffoo -fbar -include-pch %t -ast-dump-all -ast-dump-filter Whatever /dev/null \
>    // RUN: | sed -e "s/ <undeserialized declarations>//" -e "s/ imported//" \
>    // RUN: | FileCheck %s --strict-whitespace
>
> 2) For tests autogenerated with make-ast-dump-check.sh, generate the test with the
>    recently added option "generate_serialization_test=1".
>
> This will of course not find every serialization bugs. However given the tiny additional
> cost (a few RUN lines), I don't see any downsides.
>
> Thanks!
>
> Bruno Ricci
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev