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

@Quuxplusone thank you for the input! I think it is a good idea if the library-implementors take a look at it. I myself don't have enough knowledge of C++ and the libraries to judge all this stuff.
So who to ping or to add as reviewer?

In D72217#1807941, @njames93 wrote:

What do you think about volatile qualifiers. Personally I don't think its important to qualify an volatile on a pointer that is volatile, but i should adhere to the decl being declared as volatile

volatile auto X = getPointer();
//transform to
auto *X volatile = getPointer();

auto X = getVolatilePointer();
//transform to
auto *X = getVolatilePointer();

LGTM! Thank you for fixing this issue. Can you please update the bug report as well?

In D72217#1809721, @njames93 wrote:

In D72217#1809685, @njames93 wrote:

In D72217#1809212, @Eugene.Zelenko wrote:

By the word, will be interesting to see results of this check run on LLVM code. Probably results should be split on modules.

So ran it on clang and clang-tidy just crashed, gonna debug it see whats happening

Crash fixed heres what happened when I ran it on clang/lib

Quite a few occurances of const auto Decl which are renamed as const auto* const, or worse still a few that are redeclared as auto *const

/home/nathan/src/llvm-project/clang/lib/StaticAnalyzer/Checkers/MoveChecker.cpp:623:3: warning: 'const auto IC' can be declared as 'const auto *const IC' [readability-qualified-auto]
  const auto IC = dyn_cast<CXXInstanceCall>(&Call);
  ^~~~~~~~~~~
  const auto *const 
/home/nathan/src/llvm-project/clang/lib/StaticAnalyzer/Checkers/MoveChecker.cpp:636:3: warning: 'const auto MethodDecl' can be declared as 'const auto *const MethodDecl' [readability-qualified-auto]
  const auto MethodDecl = dyn_cast_or_null<CXXMethodDecl>(IC->getDecl());
  ^~~~~~~~~~~
  const auto *const

286 files changed, without looking at header files. One file failed to build which is due to a dependant template. My guess is one call will have returned a naked pointer, and another returned an iterator, maybe I should disregard dependant templates unless it would be possible to deduce its always a pointer

i am still fine with the patch. if no one else has objections, i think this can land.

I guess all the tests run?
I think this LGTM after the nits are adressed.

• fix false positive with parenListExpr, dont match so narrow for them
• try removing more false positives, does not work

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

In D54943#1804943, @JonasToth wrote:

• Merge branch 'master' into feature_transform_const.patch
• link clangAnalysis to the cppcoreguidelines-module
• fix InitListExpr as well

This last version too builds with RelWithDebInfo and fails with Debug configuration (both clean builds).

• Merge branch 'master' into feature_transform_const.patch
• link clangAnalysis to the cppcoreguidelines-module
• fix InitListExpr as well

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

In D54943#1804904, @JonasToth wrote:

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

I can't build this on top of current llvm-project tree (6a6e6f04ec2cd2f4f07ec4943036c5c2d47ce0c7):

/usr/bin/ld: lib/libclangTidyCppCoreGuidelinesModule.a(ConstCorrectnessCheck.cpp.o): in function `clang::tidy::cppcoreguidelines::ConstCorrectnessCheck::registerMatchers(clang::ast_matchers::MatchFinder*)':
/home/florin/tools/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/ConstCorrectnessCheck.cpp:65: undefined reference to `clang::ast_matchers::decompositionDecl'

I am building using clang++-9 from Debian, and diff7 applied cleanly.

Jonas, is it possible to rebase this on top of llvm-project and push it to a branch on https://github.com/JonasToth/llvm-project ?

I just merged master into the branch and pushed to feature_transform_const.patch branch in my fork. Maybe that works?
If you want you can join IRC, its faster to get this fixed there :)

Strange - I have checked out your branch, and the patch is correct (no difference between when I apply the phabricator diff7 on top of upstream llvm-project and when i look at feature_transform_const.patch)

I am using the following cmake configuration:

cmake ../llvm \
   -DCMAKE_INSTALL_PREFIX=/opt/clang10 \
   -DCMAKE_C_COMPILER=/usr/bin/clang-9 \
   -DCMAKE_CXX_COMPILER=/usr/bin/clang++-9 \
   -DCMAKE_BUILD_TYPE=Debug \
   -DLLVM_TARGETS_TO_BUILD=X86 \
   -DLLVM_ENABLE_THREADS=On \
   -DLLVM_INSTALL_TOOLCHAIN_ONLY=On \
   -DLLVM_USE_SPLIT_DWARF=On \
   -DLLVM_BUILD_TESTS=ON \
   -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;libunwind;lldb;compiler-rt;lld;clang-tools-extra;" \
   -GNinja

What cmake configuration are you using?

(Sorry - I need to go, no time for IRC today)

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

I can't build this on top of current llvm-project tree (6a6e6f04ec2cd2f4f07ec4943036c5c2d47ce0c7):

/usr/bin/ld: lib/libclangTidyCppCoreGuidelinesModule.a(ConstCorrectnessCheck.cpp.o): in function `clang::tidy::cppcoreguidelines::ConstCorrectnessCheck::registerMatchers(clang::ast_matchers::MatchFinder*)':
/home/florin/tools/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/ConstCorrectnessCheck.cpp:65: undefined reference to `clang::ast_matchers::decompositionDecl'

I am building using clang++-9 from Debian, and diff7 applied cleanly.

Jonas, is it possible to rebase this on top of llvm-project and push it to a branch on https://github.com/JonasToth/llvm-project ?

+1 for the check from me as well :)

clang/lib almost transforms cleanly.
issues still left:

• InitListExpr can initialize non-const references. Such cases are not figured out yet (see create_false_positive at the end of the testcases)
• I found a case in clang, where const was correctly added to a variable, but that variable was used in a conditional operator (foo ? const_var : non_const_var) which broke compilation. I will not fix this, as this is extremly rare (I suppose) and in a sense defeats the purpose of our analysis. I think something like this should be fixed by hand with a NOLINT.

• find more false positives
• fix false positive with refernces to containers in range-for. This introduces false negative though
• new test-case for check
• fix range-for iterator speciality; start working on complex conditional and comma-operator expression that result in a mutation on a variable
• ignore implicit casts for member-call expr
• fix another false positive in typeDependent contexts and memberExpr instead of cxxMemberCallExpr
• add test for overloaded operator>>
• add test for templated operator>>
• another case fixed
• add test for member access in for loop init
• fix false positive with member access with implicit cast between sub and base-class
• address explicit cast to references of an element

i think it would be easier to review if there are two patches, one refactoring and one new check.

any news here? do you plan to finish this patch @Quolyk ?
Do you mind if someone comandeers this patch?

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

This patch does not build on top of current tree:

/usr/bin/ld: lib/libclangTidyCppCoreGuidelinesModule.a(ConstCorrectnessCheck.cpp.o): in function `clang::tidy::cppcoreguidelines::ConstCorrectnessCheck::registerMatchers(clang::ast_matchers::MatchFinder*)':
/home/florin/tools/llvm-project/clang-tools-extra/clang-tidy/cppcoreguidelines/ConstCorrectnessCheck.cpp:65: undefined reference to `clang::ast_matchers::decompositionDecl'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[2771/4997] Building CXX object tools/clang/tools/extra/clang-include-fixer/find-all-symbols/CMakeFiles/obj.findAllSymbols.dir/PragmaCommentHandler.cpp.o
ninja: build stopped: subcommand failed.

This is my top of the tree right now:

b7ecf1c1c373c53183ef6ef66efbe4237ff7b96d (origin/master, origin/HEAD, master) NFC: Fix trivial typos in comments

@aaron.ballman @alexfh i find this change useful, as there would always be an issue with templates in the unit-test code and msvc environments. Without this default argument each runCheckOnCode<>(Code, ....) would require 4 arguments as the additional options is the 4th default-argument.
If this is not ok, it can be reverted. That will break the unit-test for the const-utility.

In D54395#1803552, @thakis wrote:

This breaks tests on Windows: http://45.33.8.238/win/5061/step_8.txt

Please take a look, and if takes a while to investigate, please revert in the meantime. (Probably needs the fno-delayed-template-instantiation kludge that's in many other tests.)

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

0001-Add-extra-tests.patch3 KBDownload

shows a couple of false positives.

• ignore implicit casts in memberExpr(hasObjectExpression())
• implement functionality for function pointers

Thank you for all the review over the time this took to land! :)

In D72121#1803242, @njames93 wrote:

Ahh clang format script must have run, I'll undo that. I've not tried running it against the whole of llvm as I don't know what the easy way to do that is, especially given that llvm disregards it's standard naming convention for old projects and stl like containers. The comment is just in relation to the bug report that this fix is based on, could probably go

Thank you for fixing these bugs!
Did you try running the check of clang/llvm again, to see if there are still missing cases of this?