Interesting, so is the advantage of that approach that any fixit Replacement or Insertion that ends with a semicolon would have it removed if a semicolon already immediately follows it? That makes sense - one less thing for individual check developers to worry about.
I can take a look at doing that.
Should clang::format::cleanupAroundReplacements() handle this instead?
Wed, Nov 13
Are you using the lexer-util functions? Maybe i am just to tired, but they seem to be unused.
Please mention this improvement in the release notes as well :)
Did you check on a real code-base that suffers from the issue, if that works as expected?
Mon, Nov 4
Yeah! nice work :)
Oct 15 2019
But i was inactive for a long time, if @aaron.ballman accepts as well you can commit instantly. Otherwise please let the other people that commented some time to react. :)
Oct 12 2019
Oct 11 2019
Do you know who is responsible for it? Because i haven't worked with documentation before and don't know what i need to do to update it.
The new switch needs documentation as well, and maybe even a note in the release notes (as it is publicly discussed as issue?).
Otherwise I am fine with the changes!
Oct 10 2019
In my opinion this check should be disabled in case of integer literals, since there are a lot of existing code (even in system libraries) where user can do nothing, e.g.:
I think that this check should behave how the coding standard dictates it behaves. By my reading of HIC++, the check is behaving by design. I think there are a few ways forward though (not mutually exclusive):
0) See if the HIC++ folks are interested in clarifying their standard for integer literals and if they are, modify the check
- Add an off-by-default option that suppresses the diagnostic with positive integer literals so that users can explicitly decide to deviate locally
- Document that this happens and is expected behavior; users can disable the check if they don't wish to conform to that standard.
Sep 12 2019
Sorry for the long delay!
Jul 30 2019
A general comment: "misc" is a sort of a heap of checks that otherwise don't have a good home. This one would probably better go to bugprone (or maybe there's a relevant CERT or C++ Core Guidelines rule?).
The closest I could find is ES.20 "Always initialize an object": https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es20-always-initialize-an-object
So a potential name for this could be "cppcoreguidelines-init-variables". However that rule is about initializing all variables, even those in structs and classes. This is about local variables.
Jul 10 2019
Just as Sidenote in case you were not aware: There is a check in clang-tidy for gsl::owner (https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-owning-memory.html)
It will benefit from your annotation and can be simplified.
May 26 2019
Could you please run this check over LLVM and give a short report of your finding? I would imagine that there is a lot of duplication, given the include-heavy nature of big c++ code bases.
May 20 2019
Wow, a lot of work!
May 16 2019
Given this revision is accepted and seems ready to go: Do you need someone to commit on your behalf?
Thans for the patch!
Thank you for the patch and sorry for the long delay.
LGTM then, i can commit for you again?
Yes someone has to do it on behalf of you.
I did so for you. After a view good patches you can get commit rights from chris lattner, until then the reviewer can commit for you.
May 15 2019
[...] please ensure that e.g. clang-analyzer-* output looks proper as well and -quiet does, too.
OK, are there any (unit) tests which I should run? If yes, how exactly? I have a successfully built a fork of https://github.com/llvm/llvm-project via ninja locally, but the documentation for the various subprojects is still a bit hard to find to me. Is there a ninja target for clang-tidy-related tests? Any hints to get started would be highly appreciated.
This and the other output-related patches are my first submissions here, and they are intentionally simple to get the workflow right. My real intention is trying to improve/fix the readability-identifier-naming check/fixer, which still has a few issues.
May 13 2019
I agree with the direction, please ensure that e.g. clang-analyzer-* output looks proper as well and -quiet does, too.
May 11 2019
Hey, I do like your check!
May 7 2019
Did you run the new version over a big project like llvm again?
If yes LGTM from my side, if not please do that before committing to ensure no new/other problems creeped in.
My understanding of the directory layout guidance in the docs is that different styles get different directories.
May 6 2019
Hi trixirt and thanks for the patch!
May 3 2019
May 2 2019
I like the new framework!
Apr 10 2019
Apr 9 2019
How does that happen to be a problem? It feels that stdout.write and stderr.write should be unconnected? (if you know the reason I would like to know it too :))
Please note, that run-clang-tidy has an export-feature for the diagnostics and fix-its which might make it easier to analyze the output of clang-tidy.
Apr 7 2019
Apr 1 2019
Mar 28 2019
I think it's the easiest way to specify the bits of the ineteger type to limit the catches. In real life, I met with this overflow / infinite loop problem with 16-bit short type, so I think the real use cases are 8 and 16 bit integers. It seems intuitive to me to use the size of the loop variable's type to separate those catches which can lead broken functionality in practice from those use cases which are just integer incompatibilities.
I think the idea is good and implementation, too. If we iterate all checks anyway (probably?) we could think about adding a severity to the checks, too?
Mar 27 2019
I think in general this is a good direction. What do you think about other heuristics?
E.g. one could say that a vector will not contain more then X GB or similar. That is probably more complicated to figure out though.
Mar 21 2019
Looks like pointless code duplication that is easily avoidable.
Why not having normal overloads? The analysis for Stmt is implemented with the private methods. Explicit template specialization is a bit overkill and so easily understood (but not too complex in this case either).l
Mar 19 2019
What happens on [=]() ..., direct capture [&Columns]()... and [Columns]()...?
Mar 18 2019
Mar 15 2019
From my side its LGTM, but I would let @serge-sans-paille accept, as he is probably more familiar with python then I am.
What is the reason you want this change to happen? I think this gives the chance to create inconsistencies which we should avoid.
Mar 7 2019
@lebedev.ri @kallehuttunen what do you think of putting this into context of the proposal (i believe its being standardized with c++20) of operator==() = default and the spaceship-operator.
This check could serve as a basis to modernize the operator== to the default if appropriate and warn/diagnose in the other cases.
IMHO the check is close to being finished. please address the notes and mark them as done if finished with it. So its clear to see whats outstanding.
In my opinion the user-facing documentation misses a "Limitations" sections that shows the artificial goto example, that would show that the used mechanism doesn't handle it.
Mar 5 2019
Mar 3 2019
Mar 2 2019
Mar 1 2019
Feb 28 2019
@JonasToth I left a comment in the commit needed to fix the index.rst, which I don't think your later review fixes, sphinx complained about the rst file being an unreferenced octtree
Hmm, yeah. The laptop i have here right now does not have the dependencies installed, so yeah (you can see from all the commits i needed to do get all errors that existed).
Most of the time it works though.
Thank you for the patch!