The internal shell already supports 'cd', ‘export’ and ‘echo’ commands. This patch adds implementation of non-pipelined ‘mkdir’, ‘diff’ and ‘rm’ commands as the internal shell builtins.
Details
- Reviewers
zturner rnk dlj modocache - Commits
- rGcfb08e9e6be7: [lit] Implement non-pipelined ‘mkdir’, ‘diff’ and ‘rm’ commands internally
rG989c9e75a6fd: [lit] Implement non-pipelined ‘mkdir’, ‘diff’ and ‘rm’ commands internally
rL319528: [lit] Implement non-pipelined ‘mkdir’, ‘diff’ and ‘rm’ commands internally
rL318911: [lit] Implement non-pipelined ‘mkdir’, ‘diff’ and ‘rm’ commands internally
Diff Detail
Event Timeline
First off, let me say this is very cool. I look forward to the day when all commands are builtin, and we can switch every client to the builtin lit shell.
I have two primary thoughts upon reading the patch:
- I don't see any tests for the case where the commands *succeed*. Only for the case where they fail. Shouldn't we have some tests that verify the commands actually work?
- Now that we have upwards of 6 builtin commands, I'm starting to think they should be separated into their own file. For example, lit/test/ShellBuiltins.py We could test them via unittests (e.g. see how BooleanExpression.py implements its unit tests).
What do you think?
Update: I actually do see where you're testing that they work, but I'm not convinced that the tests are sufficient. For several reasons.
- it doesn't test that the builtin command is actually run versus the OS command. It only tests that whatever command is run doesn't fail.
- It doesn't test that the result of the command is as expected, it only tests that it doesn't return an error. For a somewhat unrealistic illustration of this, imagine that all the commands just returned success without actually doing anything. The test as it is written now would pass.
- Now that we have upwards of 6 builtin commands, I'm starting to think they should be separated into their own file. For example, lit/test/ShellBuiltins.py We could test them via unittests (e.g. see how BooleanExpression.py implements its unit tests).
What do you think?
Hi Zachary,
Many thanks for your help on reviewing the patch and sorry for my late reply.
Yes, you are right. It could be done as a follow-up patch.
Thanks,
Update: I actually do see where you're testing that they work, but I'm not convinced that the tests are sufficient. For several reasons.
- it doesn't test that the builtin command is actually run versus the OS command. It only tests that whatever command is run doesn't fail.
- It doesn't test that the result of the command is as expected, it only tests that it doesn't return an error. For a somewhat unrealistic illustration of this, imagine that all the commands just returned success without actually doing anything. The test as it is written now would pass.
Good points. I am working on this issue now.
lit/lit/TestRunner.py | ||
---|---|---|
598–601 | Can you refactor the handling of non-pipelined commands, either in this change, or split before or after? I'm imagining a dict of commands and methods that implement builtin shell commands, which would then be ripe for refactoring into a separate shell module or something. | |
605–608 | I'd be surprised if this isn't used somewhere. |
The patch updated the test (valid-shell.txt) where lit internal shell commands succeeded.
- I don't see any tests for the case where the commands *succeed*. Only for the case where they fail. Shouldn't we have some tests that verify the commands actually work?
I think it tests the lit builtin command for the following reasons:
- Lit tests enables the use of LIT’s internal shell in ShTests (\llvm\utils\lit\tests\lit.cfg) Line 14: config.test_format = lit.formats.ShTest(execute_external=False) Lit tests use internal shell instead of using external shell.
- The function _executeShCmd returns once the shell builtins commands finish. (line 571, 578 and 585 in TestRunner.py) They will not execute the OS command.
- Since all the failed tests print the builtins commands error information, the successful tests should be run using lit builtins shell.
What do you think?
- Now that we have upwards of 6 builtin commands, I'm starting to think they should be separated into their own file. For example, lit/test/ShellBuiltins.py We could test them via unittests (e.g. see how BooleanExpression.py implements its unit tests).
Thanks, I have updated the patch to solve this issue.
lit/lit/TestRunner.py | ||
---|---|---|
598–601 | It is a good idea. | |
605–608 | I'm sorry, I'm not sure about this. Could you possibly give me an explanation? Thanks. |
Updated the builtin diff shell to support ‘-u’, ‘-b’ and ‘-w’ options. Now, all llvm, and clang tests passed with both Python 2 and Python 3.
The test of MC/AsmParser/preserve-comments-crlf.s failed since it uses the unsupported diff option --strip-trailing-cr. I updated the internal diff shell command to support this option.
The previous patch doesn’t support the sequential commands, for example “mkdir existing_folder || true”. This caused sanitizer-windows test failed. The patch has been updated to support the sequential commands.
lgtm
I think the windows asan test cases should probably use mkdir -p instead but I like the changes you made to make the internal shell commands simply print to stderr and return a non-zero exit code. I think that'll be simpler and more readable when writing new test cases with the internal shell. The test will get a FAIL status instead of an UNRESOLVED status.
Can you refactor the handling of non-pipelined commands, either in this change, or split before or after? I'm imagining a dict of commands and methods that implement builtin shell commands, which would then be ripe for refactoring into a separate shell module or something.