-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[lit] Echo full RUN lines in case of external shells #66408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[lit] Echo full RUN lines in case of external shells #66408
Conversation
@llvm/pr-subscribers-testing-tools @llvm/pr-subscribers-libcxx Changes**NOTE: The first two commits in this PR should not be reviewed. They contain [D154984](https://reviews.llvm.org/D154984) and [D156954](https://reviews.llvm.org/D156954), which will be re-landed at the same time as this commit.**Before https://reviews.llvm.org/D154984 and https://reviews.llvm.org/D156954, lit reported full RUN lines in a A fix was requested at the following:
This patch does not address the case when the external shell is windows
|
The current PR replaces PR #65267 but has some notable differences:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Note: I've only looked at third commit as instructed, that is: a398f3e
Thanks for the quick review!
You mean d71c72c9f20ed34dc2fe2d0ec849a6e44dbf9d20, right? a398f3e1dfbfc83489e4d85fd74e8b3f12d469e9 is the first commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Sorry for the confusion, and thanks again for your help! My takeaway is that, for situations like this, I should link to the actual commits to avoid the ambiguity. |
Or just give the commit title. And only temporarily, I'm sure we'll all be well acquainted with github interface eventually. |
OK, did that too, in case any one else wants to take a look. I'll pull the note out when landing as it won't mean much in the final commit log. Instead of landing on a Friday, I think it will be best to wait until at least early next week. That will give more time for others to comment, and it will make it easier to respond to any immediate issues. That seems important given the trouble this series had when I tried to land it last time. Thanks again for your help in moving this along. |
Before <https://reviews.llvm.org/D154984> and <https://reviews.llvm.org/D156954>, lit reported full RUN lines in a `Script:` section. Now, in the case of lit's internal shell, it's the execution trace that includes them. However, if lit is configured to use an external shell (e.g., bash, windows `cmd`), they aren't reported at all. A fix was requested at the following: * <https://reviews.llvm.org/D154984#4627605> * <https://discourse.llvm.org/t/rfc-improving-lits-debug-output/72839/35?u=jdenny-ornl> This patch does not address the case when the external shell is windows `cmd`. As discussed at <llvm#65242>, it's not clear whether that's a use case that people still care about, and it seems to be generally broken anyway.
d71c72c
to
a76ca4c
Compare
There seems to be a race condition of sorts which has caused the test shtest-run-at-line.py to be a bit unreliable on a Windows bot: It seems like there is some extra output that is not expected that is causing the CHECK-NEXT to fail on several lines. For example:
The extra line |
Thanks for pointing that out. (And thanks for enabling FileCheck verbosity on this bot!)
Do you know why this is being printed at all? Is it reasonable to just create that directory on that bot?
I'm concerned about weakening the test and missing other problems. I might use |
Thanks for telling me how to, it is much more useful now!
I could, although I vaguely recall having similar problems in the past trying to get rid of this error, but I can try. I would prefer that the test can handle it just in case though.
I'm not sure. I think there are some tests that still do use grep, but I think the usage of it is highly discouraged these days. |
Great!
Understood.
I grepped for grep and found a number of tests still using it. I'll push a commit with this solution for now so that (hopefully) the bot is green again. We can try to find a better solution afterward. Does that seem reasonable? |
Sure, that sounds reasonable to me. |
I guess it depends on which testsuite it is. The main llvm testsuite (and the other ones that use the same base setup) rely on a handful of unix-like tools, and will implicitly try to find them from an installation of Git for Windows, unless otherwise available: https://github.com/llvm/llvm-project/blob/llvmorg-17.0.1/llvm/utils/lit/lit/llvm/config.py#L29-L34 |
This is lit's own test suite, which invokes that same |
Pushed that: aa71680. I'll keep an eye on the bots for any additional issues. |
Fixed another instance of that: 30d77fb |
Thanks for the quick fix, was just about to comment on that! Hopefully that's the last of them! |
I think we're past that problem now. The remaining failure appears to be a |
Yeah, I think so as well. I'm testing a fix for that issue. |
NOTE: The first two commits in this PR (a398f3e1dfbfc83489e4d85fd74e8b3f12d469e9 and e4c20b93fa8d49ac22f4493358a8e3c8102eaf51) should not be reviewed here. They contain D154984 and D156954, which will be re-landed at the same time as this PR. Please review the third commit (d71c72c9f20ed34dc2fe2d0ec849a6e44dbf9d20): "[lit] Echo full RUN lines in case of external shells".
Before https://reviews.llvm.org/D154984 and https://reviews.llvm.org/D156954, lit reported full RUN lines in a
Script:
section. Now, in the case of lit's internal shell, it's the execution trace that includes them. However, if lit is configured to use an external shell (e.g., bash, windowscmd
), they aren't reported at all.A fix was requested at the following:
This patch does not address the case when the external shell is windows
cmd
. As discussed at #65242, it's not clear whether that's a use case that people still care about, and it seems to be generally broken anyway.