This is an archive of the discontinued LLVM Phabricator instance.

[clang-apply-replacements] Add command line option to overwrite readonly files.
Needs ReviewPublic

Authored by zturner on Nov 21 2019, 11:07 AM.

Details

Summary

Some source code control systems attempt to prevent you from editing files unless you explicitly check them out. This makes it impossible to use certain refactoring tools such as this, since only the tool itself is able to determine the set of files that need to be modified. This patch adds a --force option which clears the read-only bit of the file so that it can be modified.

Diff Detail

Event Timeline

zturner created this revision.Nov 21 2019, 11:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 21 2019, 11:07 AM
aganea added a subscriber: aganea.Nov 21 2019, 12:44 PM

Can you add a test case for this functionality?

clang-tools-extra/clang-apply-replacements/tool/ClangApplyReplacementsMain.cpp
52

Missing full stop at the end of the string.

Also, it looks like this is doing something subtly different than what the help text says. It looks like this is overwriting the *permissions* of the file when applying replacements. Nothing seems to reset the permissions back to what they once were when the file is closed. Is that accurate?

161

Rather than spell out the type in the declaration name but use auto, how about: ErrorOr<perms> EP or something?

Can you add a test case for this functionality?

The reason there's no test case is because it seems like that wouldn't really be any different than testing the functionality of llvm::sys::fs, which should already be handled at the llvm/Support layer. There's not really any interesting logic here. I can still do one if you think it's important but that was my reasoning anyway.

Can you add a test case for this functionality?

The reason there's no test case is because it seems like that wouldn't really be any different than testing the functionality of llvm::sys::fs, which should already be handled at the llvm/Support layer. There's not really any interesting logic here. I can still do one if you think it's important but that was my reasoning anyway.

I have a slight preference for a test because it's a user-facing feature and we want to be alerted if we ever regress it. The unit tests in llvm/Support will catch if we break the underlying get/set permissions, but not the user feature (though it would be hard to break this user feature except through get/set permissions, lol). If it's hard to test for some reason, I don't insist on it.