If an external linter (like clang-format-lint) provides autofix suggestions, they are shown as diffs in the command line arc lint tool, but are only shown as a message, with no autofix diff, in the Differential web view.
For things like suggested reformattings, this is quite unhelpful, because the reviewer can’t see what the suggested reformatting was, and whether the patch submitter was right to ignore it.
Let me know if more information is needed.
Can you give me an example of a rule which is sometimes wrong and where the implied patch is not obvious from the rule name?
With GObject C, the g_object_new() function takes varargs parameters, which are of the form ‘property name’ followed by ‘value’. It’s quite nice to be able to format these in pairs on lines, e.g.:
g_object_new (SOME_TYPE,
"parameter1", value1,
"parameter2", value2,
NULL);clang-format doesn’t have a mode which allows for this (it either bin-packs all parameters onto a single line – line width permitting – or puts them on one line each). So in these cases it’s appropriate to ignore the clang-format suggestions.
I can’t think of a way to assign rule names to code reformatting changes in a way which would be easy to understand, since (I think) tools like clang-format use weighting formulae which take various things into account before suggesting a certain reformatting (see for example the [Penalty* options it takes](http://clang.llvm.org/docs/ClangFormatStyleOptions.html)).
Does that make sense?
This is relatively ripe for implementation now that inline comments support suggested edits.