Slew of indexing, code navigation, refactoring bugs in large project -- how to address?



I am working on an open-source branch of a large open-source project. There are multiple subtle CLion bugs that come to the surface, yet I have so far only been able to reproduce a few of them in a minimal way in a separate tiny test project. I have already filed the bug reports in YouTrack for what I could easily reproduce. Many bugs that I couldn't replicate still remain unreported (sorry, I have limited time to fix bugs in the IDE I'm using, I hope the authors can take this on). These bugs have stayed with me up to and including the latest version of CLion, 2018.1.3, on Linux, on two separate machines.

What I could do is make another branch for CLion developers to check out, then point them to the places where the bugs occur.
This is the repository , and we can work on the ClionBugs branch to keep communication consistent.

The code compiles just fine with g++, you can use the default CMake arguments (no additional flags to CMake), and you'll probably be able to prune off the OpenCV/Boost/VTK/GLUT requirements by very easy tweaks to the code & CMakeLists.txt files. Using the ITMLib build target should suffice. I could probably provide some (limited) assistance in getting the CMake to run (and the indexing to reveal errors).

If the developers are up to the task, the first bug (of many) that I can point out is in file ITMSceneManipulation.h on lines 34 and 40, where CLion erroneously reports "Function ResetScene is not implemented", when in fact it is implemented in ITMSceneManipluation.tpp and is being used in various places throughout the code.

Please let me know how you would like to handle this.


Hello! Thanks for reporting. I've created the issue in our tracker: Feel free to comment or upvote. Please follow it to get updates.


Thank you!

The next bug (probably related / another symptom of the same bug) is with the actual usage of this very same ResetScene function in ITMSceneManipulation.tpp on lines  34 and 142, where CLion erroneously reports "No Matching Function."

The next (unrelated) bug occurs in places like ITMCalculateWarpGradientFunctor.h: if you insert, let's say, on line 182 (or below) 

liveSdfJacobian = Vector3f(1.0f,2.0f,3.0f);

you see the false negative "types Vector3f and 'void' are not compatible". The code compiles fine, of course. Curiously, the constructor

liveSdfJacobian = Vector3f(0.0f);

works just fine (reports no error). Again, I wasn't able to reproduce this in a small project so far, unfortunately.

Please let me know if you're able to reproduce this bug. When you are, we'll proceed to the next one.


For the "No Matching Function" issue I've created

As for the issue with Vector3f: please try the latest CLion 2018.2 EAP (released yesterday) - I can't reproduce the issue in it.


Спасибо, Анна,

Я попробую, но через некоторое время, когда смогу себе позволить отвлечься от работы на установку альтернативной версии CLion.  Отрапортую, как говориться, как только, так сразу.



I confirm that I cannot reproduce the issue with Vector3f in 2018.2 EAP.
Next bug (tested in 2018.2 EAP): auto-create new templated class function declaration based on function definition generates incorrect and unnecessary template parameter lists in the declaration, which break code.

The example is on just one of the files, but the bug follows me around the entire project, wherever there is the .tpp / .h header breakdown typical for InfiniTAM. To reproduce:

  1. Open ITMScene2DSliceLogger.tpp, for example.
  2. Scroll down to line #271 and simply copy the whole definition of DrawWarpedSceneImageAroundPoint, then rename it, e.g. to DrawWarpedSceneImageAroundPoint2, as shown in the image.
  3. CLion will correctly underline it, as it's not declared. Pull up the suggestion list and issue 'Create new  function ...' as shown in the image.
  4. This will generate the following declaration on lines 108-109 of ITMScene2DSliceLogger.h
    template<typename TVoxelCanonical, typename TIndex>
    cv::Mat DrawWarpedSceneImageAroundPoint2(ITMScene <TVoxelCanonical, TIndex> *scene);
  5. This is obviously incorrect, the template parameter list shouldn't be there, since the template parameter list in the definition refers to the class, which was already defined in the header. If you try to compile with GCC, of course you'll get "error: declaration of ‘class TVoxelCanonical’" and similar errors.

[Edit] Another possible symptom of this bug or, potentially, another bug: since the indexer thinks that, in the definitions, template parameter lists refer to the function (even when properly declared, without anything extra), when starting a Doxygen comment block above the function by placing "/**" and hitting the Enter key, the block auto-generation will make a @tparam tag for each one of the parameters. This is not the expected behavior (since the parameters should be documented in the class header instead), and produces unnecessary clutter in the code that should then be manually cleaned out.


Hi, Anna, I haven't heard from you in awhile, is there any status update on this?



Sorry for the delay, I was on vacation. Created the issue based on the description:

Just in case: you can create issues in our tracker on your own. There will be no such delays in this case :)


Hi, Anna, no worries, thanks for creating the issue, and I hope your vacation went well!

I have been creating many issues on my own before I began this thread. The reason I'm hesitant to do it for these particular cases is that I cannot easily replicate them in minimalist code samples, so that the developers can easily replicate them as well. If you think it is okay for me to just open an issue in YouTrack and point the developers to the repository & branch on github, I can do this from now on.

The next one is an elusive false-positive on templated function override, which can be found in ITMDynamicSceneReconstructionEngine_CPU.h on lines 63-68.


Another super-elusive bug is a false-positive on missing default constructor in this case:

You can find it on lines 27-29 of file ITMSceneMotionTracker_CPU.h.

Luckily, the new release seemed to fix a few other bugs, but there are still some more after this. Sorry to make a burden for you.


The second one looks like

As for the first one, I have some questions. For functions, which are declared in the base class (ITMDynamicSceneReconstructionEngine) with ITMScene<TVoxelCanonical, TIndex> input parameter, everything is fine in the "ITMPlainVoxelArray" specialisation - I mean, there are no error about overriding. The errors are present only for functions which are declared in the base class (ITMDynamicSceneReconstructionEngine) with ITMScene<TVoxelCanonical, ITMVoxelBlockHash> input parameter. Since in the "ITMPlainVoxelArray" specialisation these functions have ITMScene<TVoxelCanonical, ITMPlainVoxelArray> input parameter, I find it quite reasonable. Do I miss something?

Just in case, by the "ITMPlainVoxelArray" specialisation I mean 

class ITMDynamicSceneReconstructionEngine_CPU<TVoxelCanonical, TVoxelLive, ITMPlainVoxelArray>

Ah yes, my bad, you are correct (I think for both cases). I've up-voted the second bug. For the first one, I also had incorrect signature on the second function. Somehow, this didn't result in a compilation error because that particular template wasn't instantiated yet.

The next bug is related to these... If you attempt to refactor a function name or signature for, let's say,

ITMScene<TVoxelCanonical, ITMVoxelBlockHash>* canonicalScene,
ITMScene<TVoxelLive, ITMVoxelBlockHash>* liveScene, int sourceSdfIndex, int targetSdfIndex,
bool hasFocusCoordinates, Vector3i focusCoordinates)

in the same ITMDynamicSceneReconstructionEngine_CPU.h (using the automated function refactoring feature), it will ask whether you want to refactor the base member function's signature as well (which is usually what you want to do in such cases). But even if you choose that option, it will not refactor the corresponding overriding method for the ITMPlainVoxelArray specialization (i.e. there is no option to refactor the entire member function hierarchy), resulting in broken code.


Alright, thank you so much for your help, Anna. The rest of the bugs look like they're just duplicates of those we covered previously. I'll be sure to post to YouTrack whatever I can easily replicate & report in the future, but if I cannot, I'll post here.


Thanks, Gregory! I'm glad I was helpful.