clang-format custom format specification

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

clang-format custom format specification

Valeriy Savchenko via cfe-dev
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 specification like:

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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

clang-format custom format specification

Valeriy Savchenko via cfe-dev
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format custom format specification

Valeriy Savchenko via cfe-dev
"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
<[hidden email]> 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
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format custom format specification

Valeriy Savchenko via cfe-dev
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.  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 <[hidden email]> 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
> <[hidden email]> 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
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format custom format specification

Valeriy Savchenko via cfe-dev
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 <[hidden email]> 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.

> 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 <[hidden email]> 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
> > <[hidden email]> 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
> >> [hidden email]
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format custom format specification

Valeriy Savchenko via cfe-dev
David, see my response below.

> On Sep 15, 2020, at 12:38 PM, David Blaikie <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format custom format specification

Valeriy Savchenko via cfe-dev
On Tue, Sep 15, 2020 at 1:47 PM Kyle Knoepfel <[hidden email]> wrote:

>
> David, see my response below.
>
> > On Sep 15, 2020, at 12:38 PM, David Blaikie <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>> <[hidden email]> 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
> >>>> [hidden email]
> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format custom format specification

Valeriy Savchenko 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 <[hidden email]> 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
<[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format custom format specification

Valeriy Savchenko via cfe-dev
In reply to this post by Valeriy Savchenko via cfe-dev
Hi Kyle,

A similar feature has been proposed: allowing -style to refer to a filename. Could be style=file:<path> which is pretty close...
I guess it's a little clumsier for the user (and a little less work for the style authors) than what you propose. But it's simple, which is worth something - I don't like the idea of adding things to the format file itself to facilitate this.
And it would satisfy your goal around error-reporting: -style=foobar fails with "Invalid value for -style" and a nonexistent file could do the same.

The patch https://reviews.llvm.org/D50147 got stalled over whether the files should be searched for relative to some predefined search path. I think a version that handled absolute or working-dir-relative paths would be uncontroversial. Would this work for you?

cc Typz who wrote that patch and Mydeveloperday who is the most active clang-format maintainer.

Cheers, Sam

On Tue, Sep 15, 2020 at 9:28 AM Kyle Knoepfel via cfe-dev <[hidden email]> 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 specification like:

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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format custom format specification

Valeriy Savchenko via cfe-dev
Sam thanks for the response.  Yes, a version of Typz's patch with only absolute- and relative-path support is uncontroversial (from my POV) and it would address the complications I have encountered.  Please let me know if there may be a way I could contribute to the progress of the patch....not that I would have the time to work on it. ;)

Best,
Kyle

On Sep 16, 2020, at 3:05 AM, Sam McCall via cfe-dev <[hidden email]> wrote:

Hi Kyle,

A similar feature has been proposed: allowing -style to refer to a filename. Could be style=file:<path> which is pretty close...
I guess it's a little clumsier for the user (and a little less work for the style authors) than what you propose. But it's simple, which is worth something - I don't like the idea of adding things to the format file itself to facilitate this.
And it would satisfy your goal around error-reporting: -style=foobar fails with "Invalid value for -style" and a nonexistent file could do the same.

The patch https://reviews.llvm.org/D50147 got stalled over whether the files should be searched for relative to some predefined search path. I think a version that handled absolute or working-dir-relative paths would be uncontroversial. Would this work for you?

cc Typz who wrote that patch and Mydeveloperday who is the most active clang-format maintainer.

Cheers, Sam

On Tue, Sep 15, 2020 at 9:28 AM Kyle Knoepfel via cfe-dev <[hidden email]> 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 specification like:

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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev