rename_check.py now find and renames the test file. rename_check.py
also will now use 'git mv', so the developer no longer has to manually
add the file after running the script.
Details
- Reviewers
njames93 carlosgalvezp - Commits
- rG7718422d3b78: [clang-tidy] Improve rename_check.py
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I tested with https://reviews.llvm.org/D141133 where I renamed my new check, but noticed rename_tool.py did not rename or update the check name in the test file. The result of running the updated script against my tool is on github: https://github.com/ccotter/llvm-project/commit/b0f5118d4a2d1c5100170784117b26e59d4df0bc
Thanks for the fix! Some minor comments/questions.
clang-tools-extra/clang-tidy/rename_check.py | ||
---|---|---|
75 | I'm not sure it's the responsibility of this check to do git stuff, there may be use cases where this is not wanted / users might not expect this behavior. Introducing a dependency to git might also make this script harder to unit test in the future. Thus I think it'd be better to keep the original behavior so the script has one single responsibility. What do you think @njames93 ? | |
97 | Why is this change needed? I'd expect only line 99 to be needed to fix moving the test. |
clang-tools-extra/clang-tidy/rename_check.py | ||
---|---|---|
97 | Ah, it's not needed, but I thought it was a bit cleaner to have both the globs take the same approach and be recursive, avoiding the for-loop over the subdirectories. |
clang-tools-extra/clang-tidy/rename_check.py | ||
---|---|---|
97 | Ah yes I see it now, yes it's good to keep the consistency, thanks! |
clang-tools-extra/clang-tidy/rename_check.py | ||
---|---|---|
75 | I wasn't sure about this - reverted this. Single responsibility is better. |
clang-tools-extra/clang-tidy/rename_check.py | ||
---|---|---|
75 | Yeah we shouldn't be messing with git indexes. |
I'm not sure it's the responsibility of this check to do git stuff, there may be use cases where this is not wanted / users might not expect this behavior. Introducing a dependency to git might also make this script harder to unit test in the future.
Thus I think it'd be better to keep the original behavior so the script has one single responsibility. What do you think @njames93 ?