This is an archive of the discontinued LLVM Phabricator instance.

[lit] Report line number for failed RUN command
ClosedPublic

Authored by jdenny on Mar 16 2018, 9:08 PM.

Details

Summary

When debugging test failures with -vv (or -v in the case of the
internal shell), this makes it easier to locate the RUN line that
failed. For example, clang's test/Driver/linux-ld.c has 892 total RUN
lines, and clang's test/Driver/arm-cortex-cpus.c has 424 RUN lines
after concatenation for line continuations.

When reading the generated shell script, this also makes it easier to
locate the RUN line that produced each command.

To support reporting RUN line numbers in the case of the internal
shell, this patch extends the internal shell to support the null
command, ":", except pipelines are not supported.

To support reporting RUN line numbers in the case of windows cmd.exe
as the external shell, this patch extends -vv to set "echo on" instead
of "echo off" in bat files.

Diff Detail

Repository
rL LLVM

Event Timeline

jdenny created this revision.Mar 16 2018, 9:08 PM

Your description of needing to pass -vv doesn't look accurate, doesn't the test case just pass -v?

Your description of needing to pass -vv doesn't look accurate, doesn't the test case just pass -v?

Hi Dan,

Thanks for your question, and sorry for the confusion. The existing test case isn't a good example as it exercises a test parse error rather than a normal failed RUN command. When using the external shell, -vv is indeed needed. When using the internal shell, -v would be sufficient... except I have a bug in that case.

I'm about to update the diff with new tests that should hopefully demonstrate the new feature better. It will also fix this feature for the internal shell.

jdenny updated this revision to Diff 138839.Mar 17 2018, 7:41 PM
jdenny edited the summary of this revision. (Show Details)

This update makes several improvements:

  1. Add new tests that actually check the feature this patch introduces.
  1. Fix internal shell to have that feature (only the external shell had it before).
  1. Add new test that the internal shell ":" command cannot be part of a pipeline.
jdenny updated this revision to Diff 138840.Mar 17 2018, 7:52 PM

Sorry, one more minor fix: use END. instead of trying to escape RUN commands in CHECK lines.

jdenny updated this revision to Diff 139011.Mar 19 2018, 3:10 PM
jdenny edited the summary of this revision. (Show Details)

A few more improvements:

  1. Quote entire "RUN: at line N" argument so that output from the internal shell looks better.
  1. Add tests for the case of line continuations.
  1. Adjust tests not to depend on the external shell's exact "set -x" output format.
  1. Rebase to a more recent master.
jdenny added inline comments.Mar 19 2018, 3:38 PM
utils/lit/tests/shtest-shell.py
6 ↗(On Diff #139011)

This change is unintentional. Will revert later.

jdenny updated this revision to Diff 139851.Mar 26 2018, 2:16 PM
jdenny edited the summary of this revision. (Show Details)

This update does the following:

  1. Adds a line about this feature to the lit documentation.
  2. Adds more motivation to the patch summary.
  3. Removes the unintended change I commented on before.
  4. Rebases onto a more recent master.
jdenny marked an inline comment as done.Mar 26 2018, 2:16 PM
jdenny updated this revision to Diff 140652.Apr 2 2018, 11:59 AM
jdenny edited the summary of this revision. (Show Details)

Rebased onto a more recent master.

jdenny updated this revision to Diff 141681.Apr 9 2018, 10:39 AM
jdenny retitled this revision from [lit] Add line numbers for RUN commands to shell code to [lit] Report line number for failed RUN command.
jdenny added reviewers: rnk, asmith.

Rebased onto a more recent master.

Added more reviewers who have recently modified lit.

My team has some Windows 10 and Ubuntu 14 Azure VM's that build llvm and run the clang, llvm, lld, and lldb unit tests. I kicked off a test run with this patch and can report everything looks normal. It's cool to see the run line showing up on failing tests. LGTM.

2018-04-11T19:03:16.5491363Z FAIL: lldb :: Breakpoint/case-insensitive.test (335 of 343)
2018-04-11T19:03:16.5491683Z **** TEST 'lldb :: Breakpoint/case-insensitive.test' FAILED ****
2018-04-11T19:03:16.5492308Z Script:
2018-04-11T19:03:16.5492996Z --
2018-04-11T19:03:16.5493638Z : 'RUN: at line 3'; C:/agent/_work/62/b/release/bin/clang.exe C:\agent\_work\62\s\llvm\tools\lldb\lit\Breakpoint/Inputs/case-sensitive.c -g -o C:\agent\_work\62\b\tools\lldb\lit\Breakpoint\Output\case-insensitive.test.tmp
2018-04-11T19:03:16.5494360Z : 'RUN: at line 4'; C:\agent\_work\62\b\release\bin\lldb-test.EXE breakpoints C:\agent\_work\62\b\tools\lldb\lit\Breakpoint\Output\case-insensitive.test.tmp

My team has some Windows 10 and Ubuntu 14 Azure VM's that build llvm and run the clang, llvm, lld, and lldb unit tests. I kicked off a test run with this patch and can report everything looks normal. It's cool to see the run line showing up on failing tests. LGTM.

Hi Aaron. That's great to hear. Thanks.

Are you accepting the patch, or should we wait for more eyes?

asmith accepted this revision.Apr 11 2018, 3:18 PM

Sure, I will accept it :) Good luck with the buildbots!

This revision is now accepted and ready to land.Apr 11 2018, 3:18 PM

Sure, I will accept it :)

Thanks!

Good luck with the buildbots!

Good point. I'll wait until morning so I can deal with any trouble.

delcypher requested changes to this revision.Apr 12 2018, 9:45 AM
delcypher added inline comments.
utils/lit/lit/TestRunner.py
792 ↗(On Diff #141681)

The null command is pretty esoteric but occasionally useful in normal shell script. What's the reason it's not supported?
I guess we don't normally need it and it's a waste of time to implement it for the internal shell?

1367 ↗(On Diff #141681)

I think this would be more readable as

line = ": '{keyword} at line {line}'; {real_command}".format(
  keyword=keyword,
  line=line,
  real_command=line)

Or something similar. There's no reason for the \' if you use " quotes instead.

utils/lit/tests/unit/TestRunner.py
103 ↗(On Diff #141681)

Again if you use " quotes you can avoid having to escape the ' quotes.

This revision now requires changes to proceed.Apr 12 2018, 9:45 AM
jdenny added inline comments.Apr 12 2018, 9:53 AM
utils/lit/lit/TestRunner.py
792 ↗(On Diff #141681)

That would be my guess. Do you object to implementing it for this purpose?

1367 ↗(On Diff #141681)

Sure, I'll change that and the other occurrence you pointed out.

delcypher added inline comments.Apr 12 2018, 9:58 AM
utils/lit/lit/TestRunner.py
792 ↗(On Diff #141681)

I'm fine with you not implementing the null command. I was just curious. You could perhaps leave a TODO or FIXME commenting that we don't need to support it right now.

1367 ↗(On Diff #141681)

Great. I also much prefer use of python's string format function as in the example I gave but I'll leave that up to you.

jdenny added inline comments.Apr 12 2018, 10:26 AM
utils/lit/lit/TestRunner.py
792 ↗(On Diff #141681)

It seems we're miscommunicating. This does implement the null command. It just rejects the null command in a pipeline because I don't see a use for that right now.

1367 ↗(On Diff #141681)

Yeah, that looks nice too.

jdenny updated this revision to Diff 142215.Apr 12 2018, 10:35 AM
  1. Applied suggested changes to string quoting and formatting.
  1. Rebased onto a more recent master.
jdenny marked 5 inline comments as done.Apr 12 2018, 10:36 AM
jdenny added inline comments.Apr 12 2018, 2:05 PM
utils/lit/lit/TestRunner.py
792 ↗(On Diff #141681)

In case it helps to make this thread intelligible: I made my initial response here under the assumption that you were asking about the existing state of lit without my patch. There, the null command indeed is not implemented.

The null command implementation is needed by this patch so that the internal shell reports run lines as well.

Any objection?

delcypher added inline comments.Apr 12 2018, 2:32 PM
utils/lit/lit/TestRunner.py
792 ↗(On Diff #141681)

Ah sorry. I misread the code. I see now that your are adding support for the null command to the external shell in the case that there is no pipeline. This isn't mentioned in the commit message so perhaps you should mention it?

I have no objection to the code here.

jdenny edited the summary of this revision. (Show Details)Apr 12 2018, 2:42 PM
jdenny marked 6 inline comments as done.
jdenny added inline comments.
utils/lit/lit/TestRunner.py
792 ↗(On Diff #141681)

Good point. I've added that.

jdenny marked 2 inline comments as done.Apr 12 2018, 2:47 PM
jdenny updated this revision to Diff 142641.Apr 16 2018, 9:09 AM

Rebased onto a more recent master.

Fixed some indentation.

Improved a test case.

jdenny edited the summary of this revision. (Show Details)Apr 16 2018, 10:35 AM

Hi Dan. It seems as if you reviewed the whole patch, and I've made the changes you suggested. Is this ready to land?

delcypher accepted this revision.Apr 24 2018, 8:59 AM

Ping.

Sorry for the delay. LGTM. I've tested the patch on upstream LLVM and the tests seem to pass. Are you able to commit this?

This revision is now accepted and ready to land.Apr 24 2018, 8:59 AM

Ping.

Sorry for the delay. LGTM. I've tested the patch on upstream LLVM and the tests seem to pass.

No problem. Thanks!

Are you able to commit this?

Yes. Will do so shortly.

This revision was automatically updated to reflect the committed changes.
jdenny reopened this revision.Apr 25 2018, 2:49 PM

This broke windows and has been reverted. Discussion is here:

https://bugs.llvm.org/show_bug.cgi?id=37239

This revision is now accepted and ready to land.Apr 25 2018, 2:49 PM
jdenny updated this revision to Diff 144748.May 1 2018, 10:41 AM

I've attempted to replace the ":" command with "echo > null" in the case of windows cmd.exe. I don't build on windows, so someone else will have to try it, or we can let the buildbots tell us if windows is happy now.

I cleaned up the patch not to pass the "RUN:" keyword (or a customized version of it) around to parsers that don't need it.

jdenny requested review of this revision.May 1 2018, 10:42 AM

I've attempted to replace the ":" command with "echo > null" in the case of windows cmd.exe. I don't build on windows, so someone else will have to try it, or we can let the buildbots tell us if windows is happy now.

The tests work correctly on our setup (Windows 10/Python 3).

I've attempted to replace the ":" command with "echo > null" in the case of windows cmd.exe. I don't build on windows, so someone else will have to try it, or we can let the buildbots tell us if windows is happy now.

I meant "echo > nul", but the code had it right.

The tests work correctly on our setup (Windows 10/Python 3).

Good to know! Thanks!

Before committing, I'll wait a bit for a code review as I made some small but non-trivial changes.

jmorse added a subscriber: jmorse.May 2 2018, 4:28 AM

Hi, this broadly works on the Sony setup (Windows 10, python 2, batch) but I get a failing test case for "shtest-run-at-line.py", see inline comments. It seems to just be minor output differences.

For full clarity, here's the output of running lit on shtest-run-at-line.py, followed by the output that that test is testing: https://pastebin.com/XLfw4k8D

jmorse added a comment.May 2 2018, 4:37 AM

Aaannnddd, I didn't hit save in phabricator sorry, so here are those inline comments.

utils/lit/tests/shtest-run-at-line.py
21 ↗(On Diff #144748)

On Windows, the output I get here is:

Script:

echo "RUN: at line 1" > nul && true
echo "RUN: at line 2" > nul && false
echo "RUN: at line 3" > nul && true

And no subsequent trailing stderr

31 ↗(On Diff #144748)

Similar to above, on Windows I get

echo "RUN: at line 1" > nul && : first line continued to second line

Here, as well as no stderr.

jdenny added a comment.May 2 2018, 6:42 AM

Aaannnddd, I didn't hit save in phabricator sorry, so here are those inline comments.

Ah, I forgot those tests would need to be updated. Thanks! I'll work on it.

jdenny added a comment.May 2 2018, 7:05 AM

I've attempted to replace the ":" command with "echo > null" in the case of windows cmd.exe. I don't build on windows, so someone else will have to try it, or we can let the buildbots tell us if windows is happy now.

The tests work correctly on our setup (Windows 10/Python 3).

Hi Stella. Can you confirm that your setup uses bash in Windows? That would explain why you didn't see the errors Jeremy saw.

jdenny updated this revision to Diff 144913.May 2 2018, 2:01 PM

Fixed test failures for windows cmd.exe, hopefully....

I'm setting up a windows build so that others don't have to keep trying out my failed attempts at this patch. In the meantime, please try it if you like.

jdenny marked 2 inline comments as done.May 2 2018, 2:05 PM
jdenny updated this revision to Diff 145625.May 7 2018, 7:56 PM
jdenny edited the summary of this revision. (Show Details)

This fixes windows 10 with cmd.exe for me. If anyone else wants to try it out, that would be great, but it should be ready for a patch review.

jmorse added a comment.May 8 2018, 2:59 AM

Works perfectly for me on Win10 / cmd.exe, many thanks for getting that working!

jdenny added a comment.May 8 2018, 6:46 AM

Works perfectly for me on Win10 / cmd.exe, many thanks for getting that working!

Great. Thanks for trying it out!

jdenny set the repository for this revision to rL LLVM.May 24 2018, 12:36 PM

Ping.

What seems to be the problem?
This was accepted before, reverted due to windows bot breakage,
https://reviews.llvm.org/D44598#1091098 suggests that breakage is fixed.
Just commit again?

Ping.

What seems to be the problem?
This was accepted before, reverted due to windows bot breakage,
https://reviews.llvm.org/D44598#1091098 suggests that breakage is fixed.
Just commit again?

There was enough of a code change that I thought the reviewer would want to take another look. Is that not the right approach?

Ping.

What seems to be the problem?
This was accepted before, reverted due to windows bot breakage,
https://reviews.llvm.org/D44598#1091098 suggests that breakage is fixed.
Just commit again?

There was enough of a code change that I thought the reviewer would want to take another look. Is that not the right approach?

A high level question. Why are we even testing using cmd.exe with an external shell? IIRC that's not a use case LLVM uses for Windows. Instead
the internal shell is used on Windows. Is this (cmd.exe as an external shell) really something we want to support? I don't see anything desirable about supporting cmd.exe as an
external shell because that means it can be very easy to write non-portable shell tests.

Ping.

What seems to be the problem?
This was accepted before, reverted due to windows bot breakage,
https://reviews.llvm.org/D44598#1091098 suggests that breakage is fixed.
Just commit again?

There was enough of a code change that I thought the reviewer would want to take another look. Is that not the right approach?

A high level question. Why are we even testing using cmd.exe with an external shell? IIRC that's not a use case LLVM uses for Windows. Instead
the internal shell is used on Windows. Is this (cmd.exe as an external shell) really something we want to support? I don't see anything desirable about supporting cmd.exe as an
external shell because that means it can be very easy to write non-portable shell tests.

I'm not a windows developer. I fixed that because others reverted my patch when it broke windows buildbots. Someone else will have to answer. Here's the bugzilla, in case that helps:

https://bugs.llvm.org/show_bug.cgi?id=37239

A high level question. Why are we even testing using cmd.exe with an external shell? IIRC that's not a use case LLVM uses for Windows. Instead
the internal shell is used on Windows. Is this (cmd.exe as an external shell) really something we want to support? I don't see anything desirable about supporting cmd.exe as an
external shell because that means it can be very easy to write non-portable shell tests.

I'm not a windows developer. I fixed that because others reverted my patch when it broke windows buildbots. Someone else will have to answer. Here's the bugzilla, in case that helps:

https://bugs.llvm.org/show_bug.cgi?id=37239

Hmm. I'm now remembering that this patch broke only lit's own tests -- both in that bugzilla and when I eventually built it in windows myself. That supports your assessment. Then again, I didn't attempt to build all the LLVM test suites in windows.

I'll post the question in that bugzilla in case they're not following here.

Would there be any harm in committing this patch as is? If we decide to remove all support for windows cmd.exe, that should be a separate patch anyway.

rnk accepted this revision.May 30 2018, 11:27 AM

Would there be any harm in committing this patch as is? If we decide to remove all support for windows cmd.exe, that should be a separate patch anyway.

Nope, go for it.

Sorry, there were many updates, and I think every reviewer assumed someone else would stamp it.

This revision is now accepted and ready to land.May 30 2018, 11:27 AM
This revision was automatically updated to reflect the committed changes.