[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Mark de Wever via Phabricator via cfe-commits]

Mordante added a comment.

Sorry I missed your message. At the moment I don't intend to continue with this 
review. Do you want to commandeer this one or do you prefer me to abandon it?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added a comment.
Herald added a project: clang-tools-extra.

@Mordante, do you have plans to get back to this? Otherwise I'd like to pick it 
up.

I'd probably concentrate on multiple parameter support for now, and delegate 
identifier validation, typo correction for variadic functions, and the 
undocumented parameter warning to separate changes.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added a comment.

Thanks for working on this, I'd like to see this being fixed.




Comment at: clang/include/clang-c/Documentation.h:383
 CINDEX_LINKAGE
-CXString clang_ParamCommandComment_getParamName(CXComment Comment);
 

gribozavr2 wrote:
> Mordante wrote:
> > gribozavr2 wrote:
> > > Mordante wrote:
> > > > gribozavr2 wrote:
> > > > > Please don't modify existing APIs in libclang -- it provides a stable 
> > > > > API and ABI, and what has shipped, can't be changed. New 
> > > > > functionality has to be exposed as new functions, while old functions 
> > > > > should be kept working to the extent possible. It means that the 
> > > > > resulting API can be subpar, but oh well, a stable ABI is a contract 
> > > > > of libclang.
> > > > I thought I had read this API was allowed to change, but required 
> > > > adding information to the release notes. (I can't find it quickly.)
> > > > I'll undo the changes to the existing functions and add new functions 
> > > > instead.
> > > > I thought I had read this API was allowed to change
> > > 
> > > It would be interesting to find that doc. As far as I understand, 
> > > libclang has a strict API & ABI stability rule.
> > > 
> > > > I'll undo the changes to the existing functions and add new functions 
> > > > instead.
> > > 
> > > Thanks!
> > > 
> > >> I thought I had read this API was allowed to change
> > > It would be interesting to find that doc. As far as I understand, 
> > > libclang has a strict API & ABI stability rule.
> > My interpretation of 
> > http://llvm.org/docs/DeveloperPolicy.html#c-api-changes gave me this 
> > impression.
> I see. Index.h explains the policy for libclang: 
> https://github.com/llvm/llvm-project/blob/master/clang/include/clang-c/Index.h#L32-L33
> 
> If you feel like doing so, feel free to submit a patch for the developer 
> policy to clarify libclang stability guarantees.
I think @gribozavr2 is correct here, the chapter in the developer policy refers 
to the C API of LLVM, not Clang. The Clang documentation also says that 
libclang should be stable (http://clang.llvm.org/docs/Tooling.html#libclang).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Mark de Wever via Phabricator via cfe-commits]

Mordante planned changes to this revision.
Mordante marked an inline comment as done.
Mordante added inline comments.



Comment at: clang/lib/AST/CommentSema.cpp:1121
+  if (isFunctionOrMethodVariadic() &&
+  Typo.find_first_not_of('.') == StringRef::npos)
+return ParamCommandComment::VarArgParamIndex;

Mordante wrote:
> gribozavr2 wrote:
> > I'm not sure I like the heuristic.
> > 
> > ```
> > // \param foo.bar Something.
> > void foo(int foo_bar, ...);
> > ```
> > 
> > Here we would suggest to correct `foo.bar` to `...`.
> > 
> > Instead, I'd suggest to throw a "..." identifier into the typo corrector if 
> > the function is variadic, and let the edit distance decide.
> This heuristic works at the moment. The `lexIdentifier` will not accept 
> `foo.bar`. However since you requested to remove the `lexIdentifier` your 
> approach makes more sense.
Any suggestion how to do this? The `SimpleTypoCorrector` expects a `NamedDecl`, 
but AFAIK `...` isn't a `NamedDecl`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr2 added a comment.

In D71966#1840957 , @Mordante wrote:

> So if I understand correctly:
>
> - `getParamNameAsWritten` will become `getArgText`
> - The `getParamName` will do the translation from the name in the 
> documentation to the name in the current function declaration. If the 
> parameter index is invalid the function will fail (with an assertion error) 
> and not fallback to call `getArgText`.


Yes, that would be my preference. Thanks!




Comment at: clang/include/clang-c/Documentation.h:383
 CINDEX_LINKAGE
-CXString clang_ParamCommandComment_getParamName(CXComment Comment);
 

Mordante wrote:
> gribozavr2 wrote:
> > Mordante wrote:
> > > gribozavr2 wrote:
> > > > Please don't modify existing APIs in libclang -- it provides a stable 
> > > > API and ABI, and what has shipped, can't be changed. New functionality 
> > > > has to be exposed as new functions, while old functions should be kept 
> > > > working to the extent possible. It means that the resulting API can be 
> > > > subpar, but oh well, a stable ABI is a contract of libclang.
> > > I thought I had read this API was allowed to change, but required adding 
> > > information to the release notes. (I can't find it quickly.)
> > > I'll undo the changes to the existing functions and add new functions 
> > > instead.
> > > I thought I had read this API was allowed to change
> > 
> > It would be interesting to find that doc. As far as I understand, libclang 
> > has a strict API & ABI stability rule.
> > 
> > > I'll undo the changes to the existing functions and add new functions 
> > > instead.
> > 
> > Thanks!
> > 
> >> I thought I had read this API was allowed to change
> > It would be interesting to find that doc. As far as I understand, libclang 
> > has a strict API & ABI stability rule.
> My interpretation of http://llvm.org/docs/DeveloperPolicy.html#c-api-changes 
> gave me this impression.
I see. Index.h explains the policy for libclang: 
https://github.com/llvm/llvm-project/blob/master/clang/include/clang-c/Index.h#L32-L33

If you feel like doing so, feel free to submit a patch for the developer policy 
to clarify libclang stability guarantees.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Mark de Wever via Phabricator via cfe-commits]

Mordante marked 2 inline comments as done.
Mordante added a comment.

So if I understand correctly:

- `getParamNameAsWritten` will become `getArgText`
- The `getParamName` will do the translation from the name in the documentation 
to the name in the current function declaration. If the parameter index is 
invalid the function will fail (with an assertion error) and not fallback to 
call `getArgText`.




Comment at: clang/include/clang-c/Documentation.h:383
 CINDEX_LINKAGE
-CXString clang_ParamCommandComment_getParamName(CXComment Comment);
 

gribozavr2 wrote:
> Mordante wrote:
> > gribozavr2 wrote:
> > > Please don't modify existing APIs in libclang -- it provides a stable API 
> > > and ABI, and what has shipped, can't be changed. New functionality has to 
> > > be exposed as new functions, while old functions should be kept working 
> > > to the extent possible. It means that the resulting API can be subpar, 
> > > but oh well, a stable ABI is a contract of libclang.
> > I thought I had read this API was allowed to change, but required adding 
> > information to the release notes. (I can't find it quickly.)
> > I'll undo the changes to the existing functions and add new functions 
> > instead.
> > I thought I had read this API was allowed to change
> 
> It would be interesting to find that doc. As far as I understand, libclang 
> has a strict API & ABI stability rule.
> 
> > I'll undo the changes to the existing functions and add new functions 
> > instead.
> 
> Thanks!
> 
>> I thought I had read this API was allowed to change
> It would be interesting to find that doc. As far as I understand, libclang 
> has a strict API & ABI stability rule.
My interpretation of http://llvm.org/docs/DeveloperPolicy.html#c-api-changes 
gave me this impression.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr2 added inline comments.



Comment at: clang/include/clang-c/Documentation.h:383
 CINDEX_LINKAGE
-CXString clang_ParamCommandComment_getParamName(CXComment Comment);
 

Mordante wrote:
> gribozavr2 wrote:
> > Please don't modify existing APIs in libclang -- it provides a stable API 
> > and ABI, and what has shipped, can't be changed. New functionality has to 
> > be exposed as new functions, while old functions should be kept working to 
> > the extent possible. It means that the resulting API can be subpar, but oh 
> > well, a stable ABI is a contract of libclang.
> I thought I had read this API was allowed to change, but required adding 
> information to the release notes. (I can't find it quickly.)
> I'll undo the changes to the existing functions and add new functions instead.
> I thought I had read this API was allowed to change

It would be interesting to find that doc. As far as I understand, libclang has 
a strict API & ABI stability rule.

> I'll undo the changes to the existing functions and add new functions instead.

Thanks!




Comment at: clang/include/clang/AST/Comment.h:781
+  /// @param Idx The index of the identifier in the \\param command.
+  StringRef getParamName(unsigned Idx) const LLVM_READONLY {
+return getArgText(Idx);

Mordante wrote:
> gribozavr2 wrote:
> > Users can already call getArgText, do we need a second function that does 
> > the same?
> I thought it made sense to offer these helper functions. `getParamName` seems 
> clearer than `getArgText`. Of course it's also possible to add documentation 
> instead of a helper function. What do you prefer?
> 
> Note: This function is the replacement of `getParamNameAsWritten`, so I can 
> also reinstate its former name.
I prefer using `getArgText`. It works uniformly for all block commands.



Comment at: clang/lib/AST/Comment.cpp:376
+  case InvalidParamIndex:
+return getParamName(Idx);
+

Mordante wrote:
> gribozavr2 wrote:
> > Previously, it was necessary for the index to be valid. Why relax the 
> > contract? (This change also makes things in consistent with, say, TParam).
> IMO it makes it easier on the caller site. If it wants the name of the 
> variable in the current `FullComment` context they can simply call this 
> function. Then they don't need to validate whether the index is valid or not. 
> (I intend to do a similar patch for TParam.)
The issue is that it is unclear what kind of name they get -- the as written 
name, or the mapped one.



Comment at: clang/lib/AST/CommentSema.cpp:852
+  OrphanedParamDecls.erase(OrphanedParamDecls.begin() +
+   CorrectedParamIndex);
+}

Mordante wrote:
> gribozavr2 wrote:
> > I'm not sure about this `erase` call. With this change, once a typo claims 
> > an identifier, it is gone no matter how bad the typo was. Even if there's a 
> > further, closer, typo, that identifier won't be suggested anymore.
> True, but I thought it was not allowed for fixits to give invalid hints. 
> Using the same correction twice will result in new warnings. What do you 
> think?
> True, but I thought it was not allowed for fixits to give invalid hints.

Fixits are allowed to be incorrect. Any fixit can be incorrect semantically 
(the user actually intended something different), even if it perfectly fixes 
the C++ and Doxygen issues.

> Using the same correction twice will result in new warnings.

I don't think users will apply all fixits without subsequent review. In an IDE 
setting, users pick and choose fixits.

Also, not reusing the same correction twice does not guarantee that the fixes 
are correct; it only ensures that we won't have a new warning about duplicated 
parameter names.



Comment at: clang/lib/AST/JSONNodeDumper.cpp:1586
+for (unsigned I = 0; I != E; ++I) {
+  Params.push_back(C->getParamName(FC, I));
+

Mordante wrote:
> gribozavr2 wrote:
> > Despite what the old code does (I didn't review it when it was submitted), 
> > I think it is more useful to dump the parameter name as written, not as 
> > found in the function declaration.
> You want the behaviour for all AST dumpers? (I assume yes)
Yes, I'd prefer it everywhere.



Comment at: clang/lib/Index/CommentToXML.cpp:748
+  if (E) {
+Result << "";
+for (unsigned I = 0; I != E; ++I) {

Mordante wrote:
> gribozavr2 wrote:
> > Why do we need an extra "" wrapping the list of parameters?
> What would you propose instead? No "" and just a list of 
> "" ?
Yep, "" can directly contain multiple "" tags.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Mark de Wever via Phabricator via cfe-commits]

Mordante marked 14 inline comments as done.
Mordante added a comment.

Thanks for the review!

I only answered to the larger issues to get a better feeling of the direction 
the patch should go. Once that's clear I'll make a new patch and also address 
the smaller issues.




Comment at: clang/include/clang-c/Documentation.h:383
 CINDEX_LINKAGE
-CXString clang_ParamCommandComment_getParamName(CXComment Comment);
 

gribozavr2 wrote:
> Please don't modify existing APIs in libclang -- it provides a stable API and 
> ABI, and what has shipped, can't be changed. New functionality has to be 
> exposed as new functions, while old functions should be kept working to the 
> extent possible. It means that the resulting API can be subpar, but oh well, 
> a stable ABI is a contract of libclang.
I thought I had read this API was allowed to change, but required adding 
information to the release notes. (I can't find it quickly.)
I'll undo the changes to the existing functions and add new functions instead.



Comment at: clang/include/clang/AST/Comment.h:781
+  /// @param Idx The index of the identifier in the \\param command.
+  StringRef getParamName(unsigned Idx) const LLVM_READONLY {
+return getArgText(Idx);

gribozavr2 wrote:
> Users can already call getArgText, do we need a second function that does the 
> same?
I thought it made sense to offer these helper functions. `getParamName` seems 
clearer than `getArgText`. Of course it's also possible to add documentation 
instead of a helper function. What do you prefer?

Note: This function is the replacement of `getParamNameAsWritten`, so I can 
also reinstate its former name.



Comment at: clang/include/clang/AST/Comment.h:804
+assert(Idx < ParamIndex.size());
+return !isVarArgParam(Idx) && ParamIndex[Idx] != InvalidParamIndex;
   }

gribozavr2 wrote:
> Why does vararg have an invalid index? Previously it was considered valid.
Before a lot of code first tested whether the index was valid and then 
depending on the vararg state do a different codepath. I thought it was very 
confusing that if the function returned `true` it was no guarantee it was safe 
to access `DeclInfo::ParamVars[Idx]`.



Comment at: clang/include/clang/Basic/DiagnosticCommentKinds.td:113
+def warn_doc_param_undocumented : Warning<
+  "parameter '%0' is not documented">,
+  InGroup, DefaultIgnore;

gribozavr2 wrote:
> This warning should be in a separate group. `-Wdocumentation` contains 
> generally useful, non-controversial stuff (that would have been an error if 
> documentation comments were a part of the language). Warning about every 
> undocumented parameter is only useful for certain style guides.
> 
> (Digression: And even then, I personally question the value of a style rule 
> that requires every parameter (or every public API, or every file, or every 
> whatever else) to be documented. Unless there's a tech writer on the team, in 
> response to a such rule engineers are highly likely just to write useless 
> comments like "\param frobnicator The Frobnicator necessary for this call." 
> Engineers are already doing the best they can when writing comments. The 
> choice we have is not between "no comments for some parameters" and "good 
> comments for every parameter because the warning reminded you", it is between 
> "no comments for some parameters" and "placeholder stuff that people will 
> write to make the warning go away".)
> 
> I'd also suggest to implement this functionality in a separate patch.
I'll move it to its own patch.



Comment at: clang/lib/AST/Comment.cpp:376
+  case InvalidParamIndex:
+return getParamName(Idx);
+

gribozavr2 wrote:
> Previously, it was necessary for the index to be valid. Why relax the 
> contract? (This change also makes things in consistent with, say, TParam).
IMO it makes it easier on the caller site. If it wants the name of the variable 
in the current `FullComment` context they can simply call this function. Then 
they don't need to validate whether the index is valid or not. (I intend to do 
a similar patch for TParam.)



Comment at: clang/lib/AST/CommentSema.cpp:758
+WarnUndocumentedParameters = true;
+StringRef ParamName = PCC->getParamName(Idx);
 

gribozavr2 wrote:
> Here's one reason why I find the fallback in `getParamName` to be 
> questionable -- with the fallback, the function does different things 
> depending on the phase of processing. Sometimes it returns the original name 
> as written (before the index is set), and sometimes it returns the name from 
> the function declaration (which can be different, as far as I understand). 
> I'd much prefer to call `getParamNameAsWritten` here.
The difference is now in the `FullComment` argument instead of the name. But it 
seems that is not clear.



Comment at:

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr2 added a comment.

Thank you for the patch!




Comment at: clang/docs/ReleaseNotes.rst:68
+- -Wdocumentation properly handles Doxygen comments with multiple identifiers 
in
+  one \param command. The validation whether the name of the identifier is 
valid
+  has been improved.

validation *of*



Comment at: clang/docs/ReleaseNotes.rst:360
+- Function ``clang_ParamCommandComment_getNumParams`` has been added to
+  determine the number of parameters to a single Doxygen \param command.p
+- Function ``clang_ParamCommandComment_isVarArgParam`` has been added to

Need backticks around \param. Also a spurious "p" at the end of the line.



Comment at: clang/include/clang-c/Documentation.h:383
 CINDEX_LINKAGE
-CXString clang_ParamCommandComment_getParamName(CXComment Comment);
 

Please don't modify existing APIs in libclang -- it provides a stable API and 
ABI, and what has shipped, can't be changed. New functionality has to be 
exposed as new functions, while old functions should be kept working to the 
extent possible. It means that the resulting API can be subpar, but oh well, a 
stable ABI is a contract of libclang.



Comment at: clang/include/clang/AST/Comment.h:715
 private:
-  /// Parameter index in the function declaration.
-  unsigned ParamIndex;
+  /// The index of the identifier in the function declaration.
+  MutableArrayRef ParamIndex;

"Indices of the parameters referenced by this command in the function 
declaration."



Comment at: clang/include/clang/AST/Comment.h:763
 
-  StringRef getParamName(const FullComment *FC) const;
+  void setParamIndex(MutableArrayRef Idx) {
+assert(ParamIndex.empty() && "Can't initialize more than once.");

`setParamIndices`



Comment at: clang/include/clang/AST/Comment.h:781
+  /// @param Idx The index of the identifier in the \\param command.
+  StringRef getParamName(unsigned Idx) const LLVM_READONLY {
+return getArgText(Idx);

Users can already call getArgText, do we need a second function that does the 
same?



Comment at: clang/include/clang/AST/Comment.h:793
+
+  SourceRange getParamRange(unsigned Idx) const LLVM_READONLY {
+return getArgRange(Idx);

Ditto, duplicated API.



Comment at: clang/include/clang/AST/Comment.h:797
 
-  void setIsVarArgParam() {
-ParamIndex = VarArgParamIndex;
-assert(isParamIndexValid());
+  const Argument *getParam(unsigned Idx) const LLVM_READONLY {
+assert(Idx < Args.size());

I'd call it `getArgument` and define it in `BlockCommandComment`.



Comment at: clang/include/clang/AST/Comment.h:804
+assert(Idx < ParamIndex.size());
+return !isVarArgParam(Idx) && ParamIndex[Idx] != InvalidParamIndex;
   }

Why does vararg have an invalid index? Previously it was considered valid.



Comment at: clang/include/clang/AST/CommentSema.h:111
+  void
+  actOnParamCommandParamNameArg(ParamCommandComment *Command,
+ArrayRef Args);

s/NameArg/NameArgs/



Comment at: clang/include/clang/Basic/DiagnosticCommentKinds.td:113
+def warn_doc_param_undocumented : Warning<
+  "parameter '%0' is not documented">,
+  InGroup, DefaultIgnore;

This warning should be in a separate group. `-Wdocumentation` contains 
generally useful, non-controversial stuff (that would have been an error if 
documentation comments were a part of the language). Warning about every 
undocumented parameter is only useful for certain style guides.

(Digression: And even then, I personally question the value of a style rule 
that requires every parameter (or every public API, or every file, or every 
whatever else) to be documented. Unless there's a tech writer on the team, in 
response to a such rule engineers are highly likely just to write useless 
comments like "\param frobnicator The Frobnicator necessary for this call." 
Engineers are already doing the best they can when writing comments. The choice 
we have is not between "no comments for some parameters" and "good comments for 
every parameter because the warning reminded you", it is between "no comments 
for some parameters" and "placeholder stuff that people will write to make the 
warning go away".)

I'd also suggest to implement this functionality in a separate patch.



Comment at: clang/lib/AST/Comment.cpp:376
+  case InvalidParamIndex:
+return getParamName(Idx);
+

Previously, it was necessary for the index to be valid. Why relax the contract? 
(This change also makes things in consistent with, say, TParam).



Comment at: clang/lib/AST/CommentParser.cpp:362
+  do {
+if (Retokenizer.lexIdentifier(Arg)) {
+  ArgumentTokens.push_back(Arg

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[pre-merge checks [bot] via Phabricator via cfe-commits]

merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon times-circle color=red} clang-tidy: fail. Please fix clang-tidy findings 
.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-tidy.txt 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Mark de Wever via Phabricator via cfe-commits]

Mordante added a comment.

The merge bot noticed I forgot to update clang's unittests. Will look at that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[pre-merge checks [bot] via Phabricator via cfe-commits]

merge_guards_bot added a comment.

{icon question-circle color=gray} Unit tests: unknown.

{icon times-circle color=red} clang-tidy: fail. Please fix clang-tidy findings 
.

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

Build artifacts 
: 
diff.json 
,
 clang-tidy.txt 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71966/new/

https://reviews.llvm.org/D71966



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits