i added reviewers, since it seems nobody takes care of this check.
remove if this was bad.

In D31370#768684, @baloghadamsoftware wrote:

The matcher in D33537 could be reused here as well. Maybe I should make it common, but it is more complex than any of the common matchers.

this check is somewhat duplicated to a check currently in review, which seemed to be abondened?

i like the generalization.

Nothing to complain from my side.
Would it make sense to add boost pairs/tuples support?
I could imagine modernize checks that would transform boost structures into the stl ones, but that's another discussion probably.

#include <string.h>
void dostuff(const char *P) {

if (strncmp(P+2,"xyz",3)==0) {}

}

Iam not super familiar with C, but the intend of the function is to check the following:

P = "foxyz", P2 = "abxyz", P3 = "opxyz", ...

And if P matches this kind of string pattern.

please note this enhancement in the ReleaseNotes.

My thoughts on the check added.
Have you run it over a big codebase? What is the turnout?

Could this check be considered as part of the Default Arguments in CppCoreGuidelines? If yes, we could alias it into the cppcoreguideline-module.

@jbcoe I dont have them, Thank you for commiting :)

commented review

• [Docs] Typos fixed
• [Doc] improve documentation on what is done in the delegation constructor check

Why does diff contain so many files?
Could you maybe merge the latest master into your branch?

• [Doc] short descript in header added

• minor fix, commas not needed in enumeration

nontypo fixes.

• [Doc] grammar and content fixed

fixed the easier issues.

• [Doc] fix the bad grammar and typos

Another thought from me:

Hi and welcome to the clang/llvm community :)

@aaron.ballman i asked on the mailing list and we had a little discussion for a general noexcept check. Most were the opinion that flow analysis should be enough.
@mboehme answered on the mailing list, i will just cite the part thats somewhat addressed to you:

• [Fix] typo for code duplication

• [Fix] wrong alias mentioned by jonathan

@jbcoe Yeah that is actually a good point. Can the aliases be configured independent with default arguments? That would be a good improvement as well. For example function-size could take different default parameters.

• [Doc] add rule to every mention of the rule number

Update the aliases to reflect the new name and link to the related rules in High Integrity C++

• [Merge] Transition to hicpp wording
• [Rename] rename safety files
• Substitute safety with hicpp
• [Doc] references to the section in hicpp added

thank you very much for dealing with this issue :)
I will update the aliases. But maybe later this week since i have an exam. :)

@jbcoe and @aaron.ballman i think an valid warning would be if there is another check in an else if statement.
so singular if(enum_value == Enum::Kind) is still ok, but another branch checking on the enum is suspiscious.

alright. then i have a good check for myself to write ;)

I like that check. But I think it could take another feature.
In my opinion it would be valueable to check if enums are compared against ints as well.

that is true as well.
lets see what the static analysis brings. maybe its easy to achieve something there.

yeah you are right.
i will look for some codebases, maybe some interesting results there.

I agree with the static analysis. Iam not capable so atm, since i have no clue how to write sensefull static analysis :) But i would like to learn it.

@aaron.ballman I would like to make this more valuable and mor applicable to other rulesets as well.
Do you think it would be enough to do the same bad logic in deallocation, without deep analysis of the exceptions that can occur and if they are caught some where?

• issues by mgehre fixed

add more complicated problematic destructor to see if hasAncestor does what i think

• [Fix] link to documentation was wrong

• [Doc] adjust docs

added my thoughts. i like the check, seems really thought out :)

please add the check in the release notes as well.

fix the link in release notes

fixed typo, updated diff

• [Fix] typo fixed

[Fix] typos in the module file - actually builds now :D

mark as done

I worked on it, sry for the long delay.
Release Note adjusted, checker doc adjusted as well. As it turns out, it is possible
to have empty lists for the function lists, so i removed this requirement in the doc.

i adjusted the docs and release notes.

• Merge branch 'master' of http://llvm.org/git/clang-tools-extra into feature_argument_count
• [Release Note] added parameterthreshold to release notes

• [Doc] adjust doc for the checker

i dont have commit rights, can you land it for me please?

Reverted formatting change to testing code

In D29267#667614, @jbcoe wrote:

@alexfh Can we defer moving this to a compiler diagnostic? I'm keen to get a target in place for people to write more safety checks.

alright :)

out of curiousity:
i would like to contribute to the safety module as well. but currently there is no starting point in master. is there a way to get some code that i can start with? I think the module file where the registration happens would be enough.

alrighty :)
i dont have commit rights though.
please some commit when accepted finally. :)

fix two typos pointed out by aaron

Adjust to issues aaron pointed out.

updated doc strings

oversaw the docs, but fixed now as well

renamed function as requested.

i think the test is not mentioned in the release notes is it?

refactored like requested.

ping

Adjusted the ugly string parsing part.

fixed issues pointed out by aaron