[PATCH] D52670: [clang-tidy] Add new 'readability-uppercase-literal-suffix' check (CERT DCL16-C, MISRA C:2012, 7.3, MISRA C++:2008, 2-13-4)

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D52670#1268564, @aaron.ballman wrote:

> In https://reviews.llvm.org/D52670#1268372, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D52670#1268347, @aaron.ballman wrote:
> >
> > > In https://reviews.llvm.org/D52670#1268170, @lebedev.ri wrote:
> > >
> > > > - Apply minor wording nits.
> > > > - For `cert-dcl16-c`, **only** consider `L`, `LL` suffixes, not **anything** else (not even `llu`).
> > >
> > >
> > > I'll find out about the DCL16-C recommendation, as I suspect the intent is to cover `lu` and `llu` but not `ul` and `ull`.
> >
> >
> > I agree, i've thought so too.
> >
> > That will open an interesting question: in `lu`, `l` should be upper-case. What about `u`? We can't keep it as-is.
> >  We will either consistently upper-case it, or consistently lower-case it.
> >  I.e. given `[lL][uU]`, should we *always* produce `Lu`, or `LU`?
>
>
> I talked to someone at CERT responsible for maintaining DCL16-C to get their opinion on tightening the wording of the rule and their stated intent is:


Thank you!

> "If the first character is 'ell', it should be capitalized. The other ells need not be, and the yew's need not be capitalized either."
> 
> e.g.,
>  11lu -> diagnose
>  11ul -> fine
>  11llu -> diagnose
>  11lLu -> diagnose
>  11Llu -> fine
>  11ul -> fine
> 
> That said, the author (and I) agree that it'd be perfectly okay to diagnose things like `11Llu` and recommend `11LLU` as a replacement.

Ok, nothing unexpected.
So the full revised list is: "L;LL:LU;LLU".


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D52670