LCppC backports: Refactorizations/Optimizations

[PKEuS]

[PKEuS]

I needed some time to find out what is going on here... Why does it fail only in unix builds? What is failing? testclangimport.cpp is not compiled on Windows at all...

[PKEuS]

It seems like that (useless) clang import code stores Variable* that get invalidated while function arguments are being added. Fixed that, however, I would still suggest to remove that clang import parser as I do not see why cppcheck needs that.

[danmar]

Fixed that, however, I would still suggest to remove that clang import parser as I do not see why cppcheck needs that.

I think it can be discussed. However there are people that do use it. And I have the feeling that clang can do a better job than cppcheck ever will with complex templates etc..

There are some fundamental problems with the cppcheck parser that would be very hard to solve. The template simplifier does not have the complete type information always we would need to instantiate templates and build asts and determine types together not having separated steps.

I am not interested to just remove clang import but maybe it can be provided in another way.

[pfultz2]

And I have the feeling that clang can do a better job than cppcheck ever will with complex templates etc..

We dont just have a problem with complex templates, we also dont handle template functions, overload resolution(even for non-templates), concept auto, and generic lambdas. We may not throw syntax errors for these issues, but we there are FPs and FNs because of either misplaced or missing type information.

This is why having clang import is good to have, and it would be nice if it could grow into something more sustainable.

The template simplifier does not have the complete type information always we would need to instantiate templates and build asts and determine types together not having separated steps.

I think I mentioned before that we could run the template simplifier after ast and symboldb so it could start taking advantage of that information. As a shortcut we could rebuild ast and symboldb from scratch, but even better would be for copyTokens to preserve the ast and symboldb information or run ast and symboldb over a partial set of tokens.

Even if we can't instantiate the template it would still be good to set the type information for template parameters, which could help some analysis. We already handle incomplete types so if we could treat templates as an incomplete type it would help as well.

I think we could improve this without needing a major rewrite, but still would be a decent amount of work to do. Either way, it still wont be as good clang's parser.

[firewave]

The changes look fine. I would prefer having the Visual Studio solution changes in a separate PR though.

FYI I have an idea on how to easily dmake the moving parts of the project files so these things should no longer split through in the future.