bersbersbers added a comment. All, thanks for considering my patch! I'll answer all messages here, and will work on the patch over the weekend most probably.
In D145435#4173875 <https://reviews.llvm.org/D145435#4173875>, @owenpan wrote: > Please refer to D125171#4167866 <https://reviews.llvm.org/D125171#4167866> to > make the case that such a feature should be added. I assume you refer to these requirements: > Each new style option must .. > > - be used in a project of significant size (have dozens of contributors) I am not sure those two apply fully, as my patch does not have a new option defining a style, but another option how to define a style. So it's more infrastructure than style IMHO, and it's hard to come up with projects using some infrastructure that does not exist yet :) Still, see below for a few argument on why one might want this. > - have a publicly accessible style guide I am not sure what a "style guide" might be in my case, and I'd be happy about any clarification. Might that simply be documentation? > - have a person willing to contribute and maintain patches That would be me :) In D145435#4174661 <https://reviews.llvm.org/D145435#4174661>, @MyDeveloperDay wrote: > This is going to need unit tests Agreed, will add some. > A full context diff I see - sorry for that, will add one with the next update. In D145435#4176109 <https://reviews.llvm.org/D145435#4176109>, @HazardyKnusperkeks wrote: > I think this would be a great feature. But I also think that it needs more > documentation. Thanks! May I ask for hints about what you would expect in addition? Something like an exact description of the syntax that the parser expects? > You also need to make sure, that we don't change that comment, that is > `SpacesInLineCommentPrefix` and `ColumnLimit` should have no effect on the > comment. That is a good point, thank you. This may actually be the hardest part (for me), but I'll give it a shot. I guess `SpacesInLineCommentPrefix` will also skip `// clang-format on/off`, so that should be simple to adapt. Let's see how hard the `ColumnLimit` thing is. In D145435#4176279 <https://reviews.llvm.org/D145435#4176279>, @owenpan wrote: > I don't understand why anyone wants to do this. [...] If I lock down the > style for the files I created as this requested feature allows, what would > happen if others need to maintain these files down the road? I see a number of settings where people might want this: - Teams not (fully) agreeing on a common style, with different people using different styles (such as `BS_Allman` vs `BS_Attach`). Not saying that should be allowed in every project, but I can easily see how allowing it can avoid conflicts if users can just impose their own style on the files they maintain. (Note that this is already possible, but only by moving each user's file into a separate directory. The proposed patch will just make it easier.) - If the previous point sounds like opening the code base for style chaos (in fact, your final question appears to suggest that a per-file style will always be incompatible with the directory style), note there can be very benign examples. A team may have agreed on a 120 column limit, but they have a file that is diffed very often and for which it makes sense to have an 80 column limit. With the proposed style comment, you can enforce that locally. Note that such a file does not go against the 120 column limit, so no one is breaking any agreed-upon rules, and no other maintainer should have a problem with that file. Another example is `MaxEmptyLinesToKeep`: a team may have agreed on 3 (or no limit at all), but one maintainer likes to keep their code vertically short at works using `MaxEmptyLinesToKeep: 1`. That file will still be compliant with the agreed-upon style. - Code and style are self-contained in a single file. If you move a file from one directory to another, it will continue to use the same style, even if the two folders use different .clang-format files. (Not saying this has to be done, but it's nice to have the option.) If you email/scp/... the file to someone, the recipient knows the format and can easily format after making changes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D145435/new/ https://reviews.llvm.org/D145435 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
