[PATCH] D154984: [lit] Drop "Script:", make -v and -a imply -vv

Mon Jul 17 16:36:25 PDT 2023

ldionne added a comment.

In D154984#4494549 <https://reviews.llvm.org/D154984#4494549>, @jdenny wrote:

> In D154984#4493934 <https://reviews.llvm.org/D154984#4493934>, @jdenny wrote:
>
>> 
>
>
>
>> There are two properties of `Script` that I like here:
>>
>> 1. It is not quoted. It is easier to copy-paste, modify and run into a terminal to reproduce the issue and iterate outside of Lit.
>
> Are you saying you have to do some sort of fixup in order to copy-paste and run it in a terminal?  Or are you saying the quoting is just annoying if you want to modify the command line?  Either way, for lit's internal shell (which your example appears to be using), I'm sure we can find a way to reduce unnecessary quoting.

It's just that the quoting is annoying. I'd be more than happy if we manage to reduce unnecessary quoting, or perhaps I just want to learn to live with it. After all, quoted commands are more copy-paste safe than unquoted ones.

>> 2. It shows all commands at once instead of showing only the ones that were executed, with output in between. If I want to know how to execute the program that was compiled above, I can easily use `Script` to figure that out. If I only have the `Command Output`, I have to search for `EXECUTED AS` through potentially a lot of output from the first command.
>
> Would it be difficult in your workflow to send it through grep?  Is there any way to format the -vv trace to make that easier?

I'm usually just eyeballing at the Lit results, so yeah I don't really want to use `grep` for that. At the same time, our `SCRIPT`s are usually not too large, so I don't think this is a huge issue.

> Would you be ok with @awarzynski's request that "Script:" is printed only with `-print-script`, which doesn't execute the test?

TBH, I'd love to avoid introducing another flag to control the output of Lit. This just seems like adding complexity to me. I think your proposed changes are better and more general, and they unblock useful feature work. I would go for the pure approach and then we can all learn to live with the new output results and improve them (without adding new flags) as we gain experience with that new output.

Again, just my .02 but I'd be fine if you didn't try to satisfy everyone's current usage. We'll learn to live with it and we'll improve the baseline output of the tool as we go, but let's not add complexity to the tool just for the sake of getting consensus here.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154984/new/

https://reviews.llvm.org/D154984