I would like to add some patch for this checker later and I found that it isn't well formatted.
Details
- Reviewers
gerazo Szelethus NoQ xazax.hun george.karpenkov - Commits
- rGb68cb5498b7d: [analyzer] GenericTaint: Fix formatting to prepare for incoming improvements.
rL349698: [analyzer] GenericTaint: Fix formatting to prepare for incoming improvements.
rC349698: [analyzer] GenericTaint: Fix formatting to prepare for incoming improvements.
Diff Detail
- Repository
- rC Clang
Event Timeline
Please don't mind me intruding.
If you create a patch for the Clang Static Analyzer, please add "[analyzer]" in the revision title, because many of us are automatically subscribed to those patches. Also, upload patches with full context.
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
I see the point here, and I think it'd be worth to just clang-format most of the files we work with, as the benefits would outweigh the drawbacks (at least eventually...), but I vaguely remember @george.karpenkov having many great points against it -- please don't commit until he can take a look :)
Hmm, actually, if you're doing changes all over the file in the followup patches, it shouldn't matter much. Let's just wait a couple days for ppl to object, now that they are subscribed.
I appreciate the cleanup in general and any work on taint analysis in particular, thanks!
Essentially, it messes with git blame, and also causes a lot of merge conflicts for downstream developers (we have a few of those). But if you plan to work on this checker actively anyway, please feel free to start with formatting.
Here's the relevant quote from the guidelines:
Our long term goal is for the entire codebase to follow the convention, but we explicitly *do not* want patches that do large-scale reformatting of existing code. On the other hand, it is reasonable to rename the methods of a class if you’re about to change it in some other way. Just do the reformatting as a separate commit from the functionality change.