Minor inline comments.

What about http://clang.llvm.org/doxygen/classclang_1_1CXXConversionDecl.html ?

One minor "typo", otherwise I think we are saying everything that could be and needs to be said. Also, @steakhal, that must have been one massive blame.

Some grammatical fixes and suggestions, inline. I might have absolutely butchered 80-col in the suggestions (thanks Phab for not showing any indication of line length...), so make sure you manually reformat the document before going forward!

In D81272#2218175, @aaron.ballman wrote:

While I agree with your observation about data and flow sensitivity, I approved on the belief that the check as-is provides enough utility to warrant adding it as-is. If someone wants to improve the check into being a CSA check, we can always deprecate this one at that point. However, if there are strong opinions that the check should start out as a CSA check because it requires that sensitivity for your needs, now's a good time to bring up those concerns.

In D81272#2218050, @aaron.ballman wrote:

Thanks to the new info, I think the check basically LGTM. Can you add some negative tests and documentation wording to make it clear that the check doesn't currently handle all logically equivalent predicates, like:

if (foo) {
} else {
  if (!foo) {
  }
}

// or
if (foo > 5) {
  if (foo > 3) {
  }
}

// or
if (foo > 5) {
  if (5 < foo) {
  }
}

(I'm assuming these cases aren't handled currently and that handling them isn't necessary to land the patch.)

In D72705#2210255, @balazske wrote:

More results in CodeChecker: emacs_errorreturn

@baloghadamsoftware Maybe there is a typo in the summary of the patch

In D84520#2206077, @balazske wrote:

Do the null pointer and invalid pointer dereference belong to the same checker, that is called NullDereference?

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?

In D75229#2189666, @abelkocsis wrote:

I have managed to improve the checker, but could not set up the test files to work only in POSIX platforms. Could you help me or show me an example?

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.

In D77150#2149870, @dkrupp wrote:

Since the analyzer cannot cannot model the size of the containers just yet (or precisely enough), what we are saying with this checker is to "always check the return value of the erase() function before use (for increment/decrement etc.) whether it is not past-end" .

Adam, are you sure that the user would like to enforce such a generic coding rule? Depending on the actual code analyzed, this would require this clumsy check at potentially too many places.

@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.

In general, the test files should be cleaned up.

As a future work, when something support ifs, it should also support ?:, and eliminate redundant conditionals from there, too.

In D79330#2035850, @balazske wrote:

I was looking at CERT ARR32-C "Ensure size arguments for variable length arrays are in a valid range". The VLA should not have a size that is larger than std::numeric_limits<size_t>::max(), in other words "fit into a size_t value", or not?

Yes creating the too large VLA in itself is not a bug, only when sizeof is called on it because it can not return the correct size. A non-fatal error is a better option, or delay the check until the sizeof call. But probably the create of such a big array in itself is sign of code smell. The array actually does not need to be created to make the problem happen, only a sizeof call on a typedef-ed and too large VLA. (What does mean that "result of sizeof is implementation-defined"? Probably it can return not the size in bytes or "chars" but something other? In such a case the checker would be not correct.)

(Maybe this will make Phab not show "✅ Accepted"...)

Please check the summary of the patch, it seems to contain old information as well.

@steakhal You might want to update the patch summary before committing this to the upstream (it still mentions "not needing a visitor" 😄)

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.

• 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.

Adding @martong, he might have knowledge about the whole summary thing as he's tinkering the(?) STL checker.

@aaron.ballman @njames93 Should I write up a pitch mail to cfe-dev about this?

In D76545#1935603, @aaron.ballman wrote:

I think we want to keep the experimental checks grouped to their parent module rather than being in a module of their own.

In D76541#1935163, @njames93 wrote:

Forgive me if I'm wrong, but these kinds of changes typically don't require a review.

• 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:

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.

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.

In D69560#1891167, @aaron.ballman wrote:

Btw, we should update the terminology in the patch to use parameter instead of argument (parameters are what the function declares, arguments are what are passed in at the call site and they bind to parameters -- the issue this check is trying to solve is on the declaration side, not the caller side).

@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).

In D69560#1889925, @vingeldal wrote:

I think this value very well may strike a good balance in that compromise but I still think it is a clear deviation from the guideline as specified.
IMO all deviations from the guideline should be explicitly requested by the user, not set by default, no matter how useful that deviation is.

In D69560#1890026, @aaron.ballman wrote:

In D69560#1889925, @vingeldal wrote:

Doesn't clang-tidy exclude warnings from system headers by default though?

Third-party SDKs are not always brought in as system headers, unfortunately. Even ignoring system and third-party headers, having two parameters of the same type is a natural occurrence for some data types (like bool) where it is going to be extremely hard to tell whether they're related or unrelated parameters.

In D74463#1888270, @aaron.ballman wrote:

I am also concerned about the false positives from this check because I don't think there's going to be an easy heuristic for determining whether two identifiers are "related" to one another.

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.

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!

@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.

In D71963#1798199, @vingeldal wrote:

• Style: things that are handled by clang-format rather than clang-tidy.

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.

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.

In D36051#1792432, @sylvestre.ledru wrote:

here is the result

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?

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.