[cfe-dev] clang-format custom format specification

[David Blaikie via cfe-dev]

On Tue, Sep 15, 2020 at 1:47 PM Kyle Knoepfel <kyleknoepfel at gmail.com> wrote:
>
> 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.

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?

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