[cfe-dev] clang-format custom format specification

[Kyle Knoepfel via cfe-dev]

David, see my response below.

> On Sep 15, 2020, at 12:38 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> I've cc'd Sam McCall who might have opinions on the specific feature
> you're suggesting. In the mean time I'd like to/be happy to drill down
> a bit more into your use case, perhaps there are other solutions or
> it'll give Sam more context when he can reply
> 
> On Tue, Sep 15, 2020 at 10:21 AM Kyle Knoepfel <kyleknoepfel at gmail.com> wrote:
>> 
>> David, the current situation I'm faced with is that we're experimenting with different formats, and there is no .clang-format file that resides in the directory hierarchy.
> 
> What sort of experiments are you running? If it's a matter of using
> different formats in different parts of the codebase, that could be
> done with more narrowly scoped .clang-format files, for instance. If
> the project isn't open to having any .clang-format files checked in
> during the experimentation phase, that's trickier - could put one
> up/above/outside the project - but couldn't do that and have different
> sub directories running different experimental formats

Yes, that is what I've settled on--placing the .clang-format file outside of the source-code tree, and doing something like:

sourcecode/...
option-a/.clang-format
option-b/.clang-format
option-c/.clang-format

Somebody then asked me to send them the 'option-c' format so they could run it on their code base.  Unfortunately, he placed the '.clang-format' file in the wrong place, ran clang-format, and received an output they thought was 'option-c' but really wasn't.  If instead he could have run something like:

clang-format -style=custom:option-c ...

then a hard failure stating "option-c format not found" (or something similar) would have been helpful.

Thanks,
Kyle 

>> Once we settle on a format, I expect the .clang-format to be included in the source-code repository, and this problem can be a non-issue.  Until we get there, however, this would be a very helpful safety mechanism.
>> 
>> That said, I'm very cognizant of the XY problem, and do not want to be a perpetrator of it.
>> 
>> Thanks for your response,
>> Kyle
>> 
>>> On Sep 15, 2020, at 3:14 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>> 
>>> "clang-format for each input file will try to find the .clang-format
>>> file located in the closest parent directory of the input file." - so
>>> it shouldn't matter which directory you invoke the command from. If
>>> you have the .clang-format file in the parent of the file you want to
>>> format, it should always get that format.
>>> 
>>> Perhaps there's something broken in your setup that's causing that
>>> behavior not to work?
>>> 
>>> On Mon, Sep 14, 2020 at 5:47 PM Kyle Knoepfel via cfe-dev
>>> <cfe-dev at lists.llvm.org> wrote:
>>>> 
>>>> Forgive me if this has already been discussed.
>>>> 
>>>> I work on projects with different formatting guidelines.  For simple cases, it is simple to embed the .clang-format file in the correct (parent) directory, run `clang-format -style=file ...` and everyone's happy.  However, it is easy to get into a situation where the wrong format is applied, especially if you accidentally invoke the command from the wrong directory.
>>>> 
>>>> Would Clang be opposed to a command line invocation such as:
>>>> 
>>>> clang-format -style=custom:my-projects-format ...
>>>> 
>>>> where a field in the .clang-format file would have the value 'my-projects-format', thus attributing the file to the format name?  If a user specified something like -style=custom:my-unsupported-format, and such a format name could not be discovered in the .clang-format file, then it would be a hard failure, not letting a silent error slip by.
>>>> 
>>>> Thanks for your input.  If it is favorable, then I'm happy to explore implementing it.
>>>> 
>>>> Kyle Knoepfel
>>>> 
>>>> Software framework group leader, Fermilab
>>>> 
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>