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

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.

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.

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

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

@Szelethus Nope.

@dcoughlin How would removing the USAGE part of the dump and keeping only the list of options and their formatted help sound? That way, this option will not invite the user to directly call the analyzer.

I think this is good. Patch still marked as Needs review for some reason. 😦 Can we look up this blocking review thing? Perhaps this could be marked ready to roll once the dependency patch is ironed out.

@Szelethus I know the dependent patch D59464 will move examples/analyzer-plugin to test/Analysis/plugins/..., but this patch still seems to affect examples/. Are you sure this is the right diff? Because you are adding brand new files and brand new "folders", I don't think that'll apply cleanly.

In case no bug reports against the checker are reported on the mailing list or Bugzilla, I wholeheartedly agree with kicking the ball here.

Yeah, it seems upstream has moved away due to @Szelethus' implementation of a much more manageable "checker dependency" system. You most likely will have to rebase your patch first, then check what you missed which got added to other merged, existing checkers.

In D35068#1361902, @Szelethus wrote:

Edit: it doesn't, but CMake is mostly a C project and it does!

In D54757#1305306, @Eugene.Zelenko wrote:

In D54757#1305114, @whisperity wrote:

Bar the previous comments, I really like this. The test suite is massive and well-constructed. Do we know of any real-world findings, maybe even from LLVM?

GCC 7 introduced -Wduplicated-branches, so will be good idea to run this check on associated regression(s).

Bar the previous comments, I really like this. The test suite is massive and well-constructed. Do we know of any real-world findings, maybe even from LLVM?

Let's register the ID...

In D53974#1294385, @ztamas wrote:

I also tested on LLVm code.
The output is here:
https://gist.github.com/tzolnai/fe4f23031d3f9fdbdbf1ee38abda00a4

I found 362 warnings.

Around 95% of these warnings are similar to the next example:

/home/zolnai/lohome/llvm/lib/Support/Chrono.cpp:64:24: warning: loop variable has narrower type 'unsigned int' than iteration's upper bound 'size_t' (aka 'unsigned long') [bugprone-too-small-loop-variable]
  for (unsigned I = 0; I < Style.size(); ++I) {

Where the loop variable has an unsigned int type while in the loop condition it is compared with a container size which has size_t type. The actual size method can be std::string::length() or array_lengthof() too.

[snip snip]

I can't see similar false positives what LibreOffice code produces.

Yes, down the line I realised the function is not needed. (It emits a diagnostic because the diagnostic comes from comparing the AST file's config blocks to the current (at the time of import) compilation.)

Test was added.

In D53334#1288057, @dblaikie wrote:

In D53334#1273877, @whisperity wrote:

@dblaikie I have created a test, but unfortunately %clang_cpp in LIT invokes clang --driver-mode=cpp which is not the same as if clang++ is called. I'm trying to construct the following command-line

clang++ -fmodules-ts -fprebuilt-module-path=%t/mods --precompile -c file.cppm -o file.pcm

However, using %clang_cc1 I can't get it to accept --precompile as a valid argument, and using %clang_cpp I get an "unused argument" warning for --precompile and the output file is just a preprocessed output (like -E), which will, of course, cause errors, but not the errors I am wanting to test about.

Hey, sorry for the delay - you can use "clang -# <other arguments>" (or "clang++ -# <other arguments>" to get clang to print out the underlying -cc1 command line that is used.

If you're changing the driver then we'd write a driver test (that tests that, given "clang -foo -###" it produces some "clang -cc1 -bar" command line to run the frontend.

But since you're changing the driver, it's not interesting to (re) test how --precompile is lowered from the driver to cc1. Instead we test the frontend (cc1) directly.

In D45050#1280831, @dyung wrote:

I have attached a bzipped preprocessed file that I can confirm will show the failure if built with clang++ version 3.7.1, specifically the version that shipped with ubuntu 14.04.5 LTS. Here is the full version information:

Ubuntu clang version 3.7.1-svn253742-1~exp1 (branches/release_37) (based on LLVM 3.7.1)

Target: x86_64-pc-linux-gnu
Thread model: posix

If you build it with “clang++ -std=c++11 NotNullTerminatedResultCheck.preproc.cpp” you should see the failure.

Updating the diff just in case so that I don't lose the test code.

@dblaikie I have created a test, but unfortunately %clang_cpp in LIT invokes clang --driver-mode=cpp which is not the same as if clang++ is called. I'm trying to construct the following command-line

Looks good.

With regards to D53352: you can change the diff related to a patch whilst keeping discuccion and metadata of the diff.

Remove the custom file paths and URLs but other than that this is pretty trivial.

@aaron.ballman Neither I nor @Charusso has commit rights, could you please commit this in our stead?