- User Since
- Oct 31 2016, 11:13 AM (137 w, 2 h)
Sun, May 26
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.
Mon, May 20
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
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
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!
This patch introduced a build-failure for the documentation builders (see http://lab.llvm.org:8011/builders/clang-tools-sphinx-docs/builds/38188/steps/docs-clang-tools-html/logs/stdio).
Please take a look at the buildbots after you committed something (http://lab.llvm.org:8011/console) to avoid such issues.
i have no clue if that is correct. i added some reviews from the CSA guys.
You can abondon this. A short justification (with reference to the other revision) on the bug report would be great!
- address review comments
- rebase to master
From my side only the nits are left.