- User Since
- Dec 6 2016, 10:52 AM (192 w, 1 d)
@baloghadamsoftware Maybe there is a typo in the summary of the patch
Mon, Aug 10
Fri, Aug 7
Wed, Aug 5
What will happen with the ability to analyse a translation unit whose target was not part of LLVM_TARGETS_TO_BUILD of the current clang binary? Will it break, because the binary lacks the information on how to generate for the given target?
Mon, Aug 3
Thu, Jul 30
After using this for a while, it feels more natural and more obvious that these are the CTE targets, not the "clang/tools" test targets.
Wed, Jul 29
Tue, Jul 28
Tue, Jul 21
@lebedev.ri If you have an idea on who's competent in accepting this change, please update the reviewers field, I'm in the dark here.
Mon, Jul 20
Tue, Jul 14
Jul 9 2020
In general, the test files should be cleaned up.
Jul 2 2020
Jun 26 2020
Jun 25 2020
As a future work, when something support ifs, it should also support ?:, and eliminate redundant conditionals from there, too.
Jun 9 2020
May 28 2020
May 15 2020
May 12 2020
(Maybe this will make Phab not show "✅ Accepted"...)
Please check the summary of the patch, it seems to contain old information as well.
May 6 2020
Apr 24 2020
@steakhal You might want to update the patch summary before committing this to the upstream (it still mentions "not needing a visitor" 😄)
Apr 23 2020
First things first, we were 50 thousand (!) patches behind reality. Rebased to master. Fixed it to compile, too. Otherwise, NFC so far.
Assuming direct control. Previous colleagues and university mates departed for snowier pastures, time to try to do something with this check.
Apr 22 2020
- Re-organised code, removed debug prints, rebased, the usual tidy-up.
- Bug fixes on certain crashes like incomplete types, conversion operator templates, etc.
- Even more bug fixes against crashes, hopefully... sorry I lost the individual commits in a squash I think
- Better organisation of code, cleanup of debug prints, fix nomenclature of functions
- Explicitly mention the first and last param of the range for clarity
- Downlift the logic of joining and breaking ranges to main patch (this isn't terribly useful at this point, but both subsequent improvements to the check depend on this change)
- Basically no longer assume that if param N can be swapped with param 1, then it can also be swapped with 2, 3, etc. without checking.
- Made the list of ignored parameter and type names configurable as a checker option
- Changed the default value of MinimumLength to 2, as prescribed in the guideline's text.
Apr 21 2020
Apr 14 2020
Adding @martong, he might have knowledge about the whole summary thing as he's tinkering the(?) STL checker.
Mar 23 2020
Mar 21 2020
- Renamed check to experimental-cppcoreguidelines-avoid-adjacent-parameters-of-the-same-type.
- s/argument/parameter/g in the code and output where appropriate.
ClangTidyForceLinker.h also contained the entries without alphabetic order.
@aaron.ballman I've gone over LLVM (and a few other projects). Some general observations:
Mar 17 2020
Feb 26 2020
Also, errors should conceptually break the operation at hand, so this thing should be a warning instead?
Do you have access to the Driver somehow? Instead of a cerr (-ish) output, something that is formatted like a "true" error diagnostic (or warning), such as "no such file or directory" would be much better, I fear this [ERROR] will simply be flooded away with the usual diagnostic output on screen, especially if multiple files are concerned.
Feb 25 2020
WIP because there's a lot of debug stuff that should be cleared out from here. This is a crude patch. It works fancy, but the code is crude.
@aaron.ballman @vingeldal I'll go over the findings (as I've run this on LLVM and various other projects, a few examples are uploaded in my first comment as HTML renders of the bug report!) soon, but I want to wait until a research paper I have based on this topic gets a final decision. (It should happen soon.) I also plan to refurbish D20689 and have it upstreamed as a "co-checker" of this (one for the interface rule, one for the call sites, they kinda want to solve different aspects of the same issue, let it be up for the project how much they wish to enforce).
Feb 24 2020
I'd rather not call them false positive because the definition of false positive is ugly and mushy with regards to this check. This check attempts to enforce an interface rule, whether you(r project) wants to adhere the rule is a concise decision. A type equivalence (or convertibility in case of the follow-up patch D75041 that considers implicit conversions) should be a "true positive" in every case, as an indicator of potentially bad design.
Jan 1 2020
There are a few really minor bug fixes, test additions, documentation update, etc. coming along soon, but I've some more pressing matters. However, please feel free to review the patch as-is!
Dec 31 2019
@vingeldal Apologies, in that case. However, I would still claim that style (as a potential severity) has its purpose for Tidy checkers, not just for clang-format.
Dec 30 2019
Dec 24 2019
The checks.rst has recently been updated to show "normal" (main entry) checks and "aliases" in different tables in D36051. Please register the alias-ness accordingly.
Dec 22 2019
Dec 20 2019
I am a little bit conflicted about the Severity column. While I know our people put a great deal of effort into keeping this classification sane, what was put into CodeChecker is, at the end of the day, a pretty arbitrary classification.
Dec 17 2019
Are buffers otherwise modelled by the Analyser, such as results of the malloc family and alloca intentionally not matched, or are there some tests missing regarding this?
Dec 12 2019
I have developed a related check in D69560. That one considers types, but is an interface rule checker, and does not consider (any) potential call sites. Moreover, it does not consider "swaps" that happen across a function call, only, as the name implies, adjacent similar-type ranges.
Dec 9 2019
Can you refresh my memory on whether a rule for "if init expr is constant, initialise in class body instead" exists for init list members? If so, this will be a funny "two pass needed to fix" kind of check.
Dec 5 2019
While I can't pitch in with actual findings of this check, @MyDeveloperDay, you're right in many aspects, including those specific examples not firing. But an example that actually fires this check indicates a very specific undefined behaviour case. So if such bogus code (that would trigger on this check) did not cause run-time issues so far, it's because they never free() their memory allocations (really bad?), or their platform is particular enough that it allows calling free into the buffer, not only for the start of the buffer.
Nov 18 2019
Oct 31 2019
- Removed This check from the documentation comment of the check's class too.
- Fix some comments, formatting and documentation
- Organised test files to be in the same directory as others on the Monorepo structure
- Helper functions moved from namespace (anonymous) to static.
- Added test for C and enabled check for C code.
Oct 29 2019
@Szelethus and @baloghadamsoftware are colleagues to me whom are far more knowledgeable about check development and I want them to see that I want a review from them. I specifically didn't do an "internal with colleagues" downstream review with regards to this code.
A few interesting "true positive" findings:
Aug 30 2019