[PATCH] Add readability-redundant-void-arg check to clang-tidy

[Gábor Horváth]

In http://reviews.llvm.org/D7639#136296, @LegalizeAdulthood wrote:

> In http://reviews.llvm.org/D7639#136280, @xazax.hun wrote:
>
> > In http://reviews.llvm.org/D7639#136129, @LegalizeAdulthood wrote:
> >
> > > If you can show me how to lex a SourceRange without getting that error, I'm happy to change it. I tried the method shown in the linked diff and I get the same error.
> >
> >
> > As far as I know, the point is that you can not do that without creating a null terminated string, however you do not need to do that. What you can do insead: you can lex the whole file buffer starting from the beginning of a declaration and you can make sure that you finish lexing on the end of the declaration (e.g.: end lexing when you match the closing paren of the declaration). This way you might have a bit more complicated lexing logic but you avoid heap allocation. So the point is: you construct the lexer using the whole file buffer starting from the right position and not relying on the source range at all to finish lexing.
>
>
> Relex the entire file just to avoid a heap allocation?  That seems a bit excessive.  Do we have any measurements on real code bases that show this to be the better approach?  I don't want to optimize like this without real data to show that it is worthwhile.
>
> Most of the time this string is going to either be "()" or "(void)".  Small string optimization means that there isn't even a heap allocation.


Well, you won't relex anything that does not need to be relexed. You only initialize the lexer using the whole buffer, so you get a null terminated string. But the starting point of the lexing would be the starting source location of the declaration you want to lex. And you would only lex the tokens you need. I think the lexer is lazy, so initializing with a bigger buffer should not cause any performance regressions in case you do not lex more tokens that you need. Of course measurements would tell this for sure.


http://reviews.llvm.org/D7639

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/