You get a const, you get a const, EVERYBODY GETS A CONST

[msooseth]

Step 1: Build with clang-tidy enabled via CMake

  cd /home/matesoos/development/solidity
  mkdir build-clang-tidy && cd build-clang-tidy
  cmake .. -DCMAKE_BUILD_TYPE=Debug \
           -DCMAKE_CXX_CLANG_TIDY="clang-tidy" \
           -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

This integrates clang-tidy into the build — every .cpp compiled will also be checked. However, this does not apply fixes automatically.

Step 2: Apply fixes using run-clang-tidy

The better approach for auto-fixing the whole codebase is using run-clang-tidy (ships with clang-tidy) on the compile commands database:

  # Generate compile_commands.json (if not done above)
  cd /home/matesoos/development/solidity/build-clang-tidy
  cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
  CCACHE_DISABLE=1 make -j8   # need a successful build first for generated headers

  # Run clang-tidy with auto-fix on all project sources
  cd /home/matesoos/development/solidity
  run-clang-tidy -p build-clang-tidy \
                 -checks='-*,misc-const-correctness' \
                 -fix \
                 -j8 \
                 'lib.*|solc/'

Step 3

????

Step 4

Profit!

[cameel]

How foolproof are these checks? Were there false-positives that you had to correct manually?

Is this reliable enough we could think about adding run-clang-tidy to the chk_style job to enforce this.

[msooseth]

ZERO false positives in the ENTIRE codebase. ZERO.

[msooseth]

straight-up fixed it and recompiled and it was fine.

[msooseth]

Notice that the only reason why the compile is failing here is because of a warning, which is that NOW the compiler sees that something could be a for(const auto& stuff: ...) -- previously, it was copied but there was no const, so the compiler didn't know if it was changed or not and hence could not warn about this.