[cfe-dev] clang-format custom format specification

[Kyle Knoepfel via cfe-dev]

>> 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.
> 
> In this case, even a "no .clang_format file found" message would've
> been adequate, yes? Or did they have some other .clang_format file?
> Perhaps in verbose mode clang-format could print which .clang_format
> file it used?

I am not certain what his particular failure mode was, but providing an error message a la your proposal and/or a verbose mode that prints the path of the .clang-format file would be quite welcome and would meet the need.

Kyle

>> 
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200915/b7cabfec/attachment-0001.html>