LGTM! thanks for fixing.

Hey Alex, first thanks for the bug fixing! Of course we are interested in improvements in clang-tidy, but i think noone is actually employed to help out here and the normal reviewers have many, many reviews parallel. Sometimes stuff just slips through :/

You can land it. Worst case would be post-commit comments, but this is not a complicated patch and should be fine!

I am fine now, thank you!

The issue is resolved now in the CppCoreGuidelines.

The context thingie was not that important here, but still thanks :)

LGTM.
Short reminder to please use full context patches. Its not an issue right now, but review sometimes just needs the context to understand the changes :)

• fix test RUN line

• no delayed template parsing
• adjust release note issue

• missed one place of decltype

• fix platform dependent warning message for decltype to just match the beginning and not the 'a.k.a'

• address review comments

• update to landed ExprMutAnalyzer changes

• [Feature] add elvis operator detection

• fix imprecisions

In D54943#2302315, @0x8000-0000 wrote:

In D54943#2292377, @0x8000-0000 wrote:

In D54943#2291969, @JonasToth wrote:

@AlexanderLanin @0x8000-0000 i created the branch release-11-const (https://github.com/JonasToth/llvm-project/tree/release-11-const) in my fork.

This branch is based on 11-rc3 and cherry picks the commits that correspond to this revision.
I hope this is of any use for you! I will probably forget to update this branch all the time, but if I feel like there has been actual progress made, i will update!

Thank you Jonas - will add this to our CI tool for the new project and try to find some time to run it on the legacy project.

Just a quick update; in clang-tidy mode it works great, with no false positive and no crashes. I haven't tried the 'apply-replacements' mode.

rebase to newest expmutanalyzer patch

@aaron.ballman I update the code a bit. This stuff is just a hydra :/

• document sections in the testcases, hopefully little more structure for comprehension
• fix derived-to-base-cast OUTSIDE of an conditional operator
• improve type-dependent callexpr, too
• better canResolveToExpr matcher code
• adjust matcher for comma

I am confused now, but richard knows this stuff very well! The patches you referenced showed only cases where the static was defined in an inline-header definition (and templates). Does this make a difference on the semantics?
This should be clear before we continue.

In D54943#2295894, @AlexanderLanin wrote:

Off-Topic: I was just attempting to apply this to my codebase at work.
Seems this will be more challenging than anticipated 😉
My best guess is this is related to D72730

Applying fixes ...
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

In D54222#2294123, @jranieri-grammatech wrote:

In D54222#1290789, @JonasToth wrote:

I agree with @Eugene.Zelenko that this check should rather live in bugprone- as the issue its diagnosing is not LLVM specific. It is ok to add an alias into the llvm module.

Here are the warnings it issues with the patch's matcher:

clang/include/clang/StaticAnalyzer/Core/CheckerManager.h:625:43: warning: address of static local variable 'tag' may not be identical across library boundaries [llvm-problematic-statics]
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:219:1: warning: address of static local variable 'Index' may not be identical across library boundaries [llvm-problematic-statics]
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h:25:1: warning: address of static local variable 'Index' may not be identical across library boundaries [llvm-problematic-statics]

And here are the additional warnings it issues when relaxing the matcher (to be unless(isExpansionInMainFile())):

clang/lib/StaticAnalyzer/Checkers/Iterator.h:130:47: warning: address of static local variable 'Index' may not be identical across library boundaries [llvm-problematic-statics]
clang/lib/StaticAnalyzer/Checkers/Iterator.h:136:47: warning: address of static local variable 'Index' may not be identical across library boundaries [llvm-problematic-statics]
clang/lib/StaticAnalyzer/Checkers/Iterator.h:142:47: warning: address of static local variable 'Index' may not be identical across library boundaries [llvm-problematic-statics]
clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPITypes.h:60:5: warning: address of static local variable 'index' may not be identical across library boundaries [llvm-problematic-statics]
llvm/utils/unittest/googletest/src/gtest.cc:3989:3: warning: address of static local variable 'instance' may not be identical across library boundaries [llvm-problematic-statics]

And also this one, which was hidden by default but made running tidy noisier by always saying there was a hidden warning:

/usr/bin/../include/c++/v1/functional:1960:9: warning: address of static local variable '__policy_' may not be identical across library boundaries [llvm-problematic-statics]

All of the first set of warnings might be actual problems, but the second set definitely aren't problems because they aren't going to be used across shared library boundaries. By making this be a LLVM-specific check, we can avoid the noise of these false positives. Also, I looked through the C++ Core Guidelines for any rules that might address this but didn't see anything relevant.

Thoughts?

• fix typo that provided wrong argument to AST building

• address review comments

• adress review comments

In D36836#2289639, @lebedev.ri wrote:

Rebased.

There is a number of official open-source LGPL-3 implementations already:

• https://github.com/SonarSource/SonarTS/pull/378
• https://github.com/SonarSource/sonar-java/pull/1385
• https://github.com/SonarSource/SonarJS/pull/449
• https://github.com/SonarSource/sonar-php/pull/173

There are other open-source LGPL-3 implementations already:

• https://pypi.org/project/cognitive-complexity/ (MIT)
• https://github.com/rossmacarthur/complexity (APACHE/MIT)

There are other 3rd party implementations:

• https://docs.codeclimate.com/docs/cognitive-complexity

Quite honestly, i do not understand how did the license question arose.
Would have it been fine if i based this on the open-source-licensed code?
Would have it not been? Would same license question be raised?
Somehow i don't think it would have been.

Is this really just about Copyright SonarSource S.A., 2018, Switzerland. All content is copyright protected. in https://www.sonarsource.com/docs/CognitiveComplexity.pdf ?
But that is only about the document, not the algorithm.
But even if we enternain the idea that all of the implementations must bow to that license,
then surely this is not the first code in LLVM that is implicitly/explicitly based on copyrighted doc.

This is rather frustrating.

@AlexanderLanin @0x8000-0000 i created the branch release-11-const (https://github.com/JonasToth/llvm-project/tree/release-11-const) in my fork.

• improve the expression matcher, to catch the expression in general ternary-operator cases, too
• considered unresolved operator calls to be a modification
• fix method calls with templates in some instances

In D54943#2289037, @0x8000-0000 wrote:

Master branch has too many false positives for tidy - would it be possible to create a branch that contains this patch set on top of llvm-11.0-rc3? I would then add this to our internal CI.

In D87588#2278948, @ro wrote:

As described in D87825, this patch broke Debug builds on sparcv9-sun-solaris2.11 and amd64-pc-solaris2.11.

In D54222#2281642, @jranieri-grammatech wrote:

@JonasToth It looks like there are some outstanding review comments that need to be addressed. I've gotten some time allocated to work on this next week.

• remove spurious formatting change

• rebase to revision for https://reviews.llvm.org/D88088

• include ExprMutAnalyzer implementation changes, that got lost somehow with prior rebase

In D54943#2255358, @AlexanderLanin wrote:

Observed behavior:

Change: for(string_view token : split_into_views(file_content, " \t\r\n")) --> for(string_view const token : split_into_views(file_content, " \t\r\n")).
Note: std::vector<string_view> split_into_views(string_view input, const char* separators);
Problem: Now it triggers error: loop variable 'token' of type 'const nonstd::sv_lite::string_view' (aka 'const basic_string_view<char>') creates a copy from type 'const nonstd::sv_lite::string_view' [-Werror,-Wrange-loop-analysis]
Fixed manually by making it for(std::string_view& const token : split_into_views(file_content, " \t\r\n")).

• rebase to master after AST Matchers are extracted

• rebase

• fix compilation error from removed brace

• fix left over merge marker and one formatting problem

Sorry for missing this review, i simply hadn't time :/
All my concerns are addressed and I think this is LGTM after rebasing.

ping.
This checks seems pretty much done. @jranieri-grammatech do you think there is something missing? Otherwise it could be rebased and comitted?

ping.
@njames93 are you revisiting this patch? What is the missing piece? Maybe i can help out a bit?

LGTM

great to see such a check!

In D54943#1841086, @AlexanderLanin wrote:

In D54943#1815772, @0x8000-0000 wrote:

This generated 56 "const const" declarations, of which 25 were triple const!

We need tests for that. There should be tests for the exporting-feature. Maybe they could provide a good starting point on adding tests. (not sure if there is unit-test code for isolated testing, but some tests do exist!)

Yeah, the libc++ failures are not your fault :)
My 2 cents added.

In D71980#1810086, @njames93 wrote:

Is this good to land and if so anyone able to commit?

K. Thank you for fixing it!

LGTM in general. The linked bug report misses a "4" --> PR44440, so please the description for that.

@gkistanova Do you know the toolchain on the power-pc builders? I get an ICE with this patch (see the prior commit) and would like to find out whats the problem. Thanks for your time!

The powerpc buildbots get an internal compiler error and crash. No Idea why, reverted for now.

• remove merge conflict markers in docs

• fix compilation error, missing getType

• add test for K&R functions

Thank you for looking into this; I'll start building diff14 to test locally.

So that is were the CTU question comes from? :)

The other recursion check seems more sophisticated. What is your take on it? Would you consider it better as well, what is your opinion on it?

@0x8000-0000 i did remove dependentTypes from matching. Locally that works with your reported test-case (i was running clang-tidy wrong :().

• fix false positive with ignoring dependentTypes

• remove pointee-analysis artifacts as this will be done later
• remove unnecessary comments

In D54943#1815358, @0x8000-0000 wrote:

Here is a minimal example that shows the problem:

#include <memory>

template<typename SomeValue>
struct DoGooder
{
    DoGooder(void* accessor, SomeValue value)
    {
    }

};

struct Bingus
{
    static constexpr auto someRandomConstant = 99;
};

template<typename Foo>
struct HardWorker
{
    HardWorker()
    {
        const DoGooder anInstanceOf{nullptr, Foo::someRandomConstant};
    }
};

struct TheContainer
{
    std::unique_ptr<HardWorker<Bingus>> m_theOtherInstance;
};

Example run:

$ /opt/clang10/bin/clang-tidy -checks="-*,cppcoreguidelines-const-correctness" -header-filter=".*" reproconst.cpp -- -std=c++17 -Wall
54 warnings generated.
reproconst.cpp:22:9: warning: variable 'anInstanceOf' of type '<dependent type>' can be declared 'const' [cppcoreguidelines-const-correctness]
        const DoGooder anInstanceOf{nullptr, Foo::someRandomConstant};
        ^
                       const
Suppressed 53 warnings (53 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.

In D54943#1815073, @0x8000-0000 wrote:

Applied the fix-it on one of our smaller (but C++ code bases) and it builds and passes the tests. Comments:

1. I'm still seeing some false positives, where some locals that are const are flagged as could be made const - I'm working to create a minimal reproduction recipe.
2. We're a west const shop :) so adding a bunch of east-consts will not fly well. Is there a way to configure where 'const' is placed by the fixit? (Specifically 'auto const', we prefer it 'const auto').

• test if references to pointers are ignored if pointers are ignored as values
• add different possible auto constellations
• document the problematic cases for 'auto' deductions

• address review comments

• fix unit tests for exprmutanalyzer, whitespace was the problem
• Merge branch 'master' into feature_transform_const.patch

• Merge branch 'master' into feature_transform_const.patch
• actually dismiss function references
• work on exclusion of variables that have type, autotype or reference-type to template parameter
• by default analyze the pointers and transform as well, for testing
• fix canResolveToExpr to account for derivedToBaseClass casts
• restore unit tests for expr mut analyzer - there was an oversight in my build that lead them not being running
• short id for matcher
• fix test for fixed false negative
• rip out unused matchers that are now unnecessary
• try to ignore auto-types that are type-dependent
• consider 'static_cast<Type&>()' always a mutation, speculativly fix tests for that

In D72438#1811776, @thakis wrote:

I'll point out that with this approach we lose all test coverage of the checker with delayed template parsing on, even though most of the test works in that mode and delayed template parsing is the default when targeting windows.

LGTM.
This check already existed in clang-tidy and had a bug. So we should fix that (thank you for that) and probably even backport (release coming soon).
So even though clang itself might be able to do it, clang-tidy should do it properly as well.

I did evaluate the performance of the check on LLVM with the script in the attachement.

Adding a -fno-delayed-template-parsing to the RUN-line should suffice.