Clang autocomplete does not work

[CyberRascal]

Hi,

I'm trying to use clang for autocompletion - I am running Archlinux and installed clang from repositories and Codelite from an AUR. The version is 3.5.5375.

I've tried both creating a Custom Makefile project and a G++ console project. Having the following main.cpp:

Code: Select all

#include <vector>

int main(int argc, char *argv[])
{
    std::vec
    return 0;
}

while having the cursor on std::vec and triggering code completion causes the error "cannot find stdarg.h" OR "cannot find stddef.h", depending on project type.

Compiling with clang from command line works fine. I've tried adding all the include paths to both workspace/codecompletion and tags/clang. This includes, but is not limited to /usr/include/c++/4.7.0/tr1/ where stdarg.h resides. Any ideas what the problem is?

I've found the following thread but it seems to relate to VIM and don't know how to replicate the solution for Codelite.

https://github.com/Rip-Rip/clang_complete/issues/109

Another minor thing: Everytime I start Codelite, it tells me to update the program, but Update now does nothing, and it seems like I already have the latest version..

Thanks for any help!

[eranif]

I'm trying to use clang for autocompletion

This is not recommended with version 3.5.X (in general the optimum settings should be ctags as #1 completion with clang as backup)
http://www.codelite.org/LiteEditor/ClangIntegration35

codelite's support for clang should work out of the box for 'g++ console project'
If your code can compile it should complete...

That said and Assuming that you are using the standard console g++ project, you should only add the "standard" ( e.g. /usr/include ) include path to clang from:
settings -> tags settings -> clang

(there is no need to mess with the workspace->code-completion settings for standard 'g++ console project', unless you know what you are doing)

you can get a more detailed information of why clang fails to complete by enabling a higher log verbosity from:
"settings -> global editor settings -> misc -> log" and set it to "Debug"

from a console terminal, type:

Code: Select all

tail -f ~/.codelite/codelite.log&

attempt to complete, and you will get a detailed information of what codelite is doing.

Note that clang support was improved significantly in trunk, so you might want to compile the latest version from trunk

Eran

[CyberRascal]

Hey, thanks for the help.

I'll use ctags atleast until I come around to compiling from source.

Logs doesn't show anything extraordinary it seems, but thanks anyway!

[CyberRascal]

Alright, decided to compile from SVN as I found a AUR that did the buildpkg stuff.

I'm running revision 5561, which seems to be the latest version. I'm running a 'custom make project' since I want an IDE-agnostic project.

I'd be fine with using ctags if it didn't give me 20x unneccesary completions, like __Iter<T> and stuff.

Anyway, clang still gives me errors - but somehow the stdarg problem isn't present anymore.

Logs tell me:

Code: Select all

[ 16:58:38:980 DBG ] Completion diagnostic [3]: This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
[ 16:58:38:980 DBG ] Completion diagnostic [3]: no type named 'shared_ptr' in namespace 'std'
[ 16:58:38:980 DBG ] Completion diagnostic [3]: expected ')'
[ 16:58:38:980 DBG ] Completion diagnostic [1]: to match this '('
[ 16:58:38:980 DBG ] Completion diagnostic [3]: no type named 'shared_ptr' in namespace 'std'
[ 16:58:38:980 DBG ] Completion diagnostic [3]: expected member name or ';' after declaration specifiers
[ 16:58:38:980 DBG ] Completion diagnostic [3]: no type named 'unordered_map' in namespace 'std'
[ 16:58:38:980 DBG ] Completion diagnostic [3]: expected member name or ';' after declaration specifiers
[ 16:58:38:980 DBG ] Completion diagnostic [3]: no member named 'unique_ptr' in namespace 'std'
[ 16:58:38:980 DBG ] Completion diagnostic [3]: 'deserializer' does not refer to a value
[ 16:58:38:980 DBG ] Completion diagnostic [1]: declared here
[ 16:58:38:980 DBG ] Completion diagnostic [3]: use of undeclared identifier 'deserializers_by_format'
[ 16:58:38:980 DBG ] Completion diagnostic [3]: no type named 'shared_ptr' in namespace 'std'
[ 16:58:38:980 DBG ] Completion diagnostic [3]: expected unqualified-id
[ 16:58:38:980 DBG ] caching Translation Unit file: /home/max/projects/revenant/include/init_helpers.hpp, 0x7fe9abc6e7e0
[ 16:58:38:980 DBG ]  ==========> [ ClangPchMakerThread ] PCH creation ended successfully <==============

I've added -std=c++11 to the Compiler Flags (clang only) in both project settings and workspace settings. In the root of my project there is a file called project.clang, which contains a single XML root node <ClangCodeCompletion />. I'm not sure how to interpret this, maybe the settings aren't persisted?

From earlier in the logs:

Code: Select all

[ 16:50:14:195 DBG ] ClangWorkerThread:: processing request 3
[ 16:50:14:195 DBG ] ClangWorkerThread:: found cached TU: (
[ 16:50:14:195 DBG ] Command Line Argument: -I/home/max/projects/revenant/include
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/include
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/include/c++/4.7.0
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/include/c++/4.7.0/x86_64-unknown-linux-gnu
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/include/c++/4.7.0/backward
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/local/include
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/include
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/include
[ 16:50:14:195 DBG ] Command Line Argument: -I/usr/include/c++/4.7.0
[ 16:50:14:195 DBG ] Command Line Argument: -I/home/me/project/include
[ 16:50:14:195 DBG ] Command Line Argument: -x
[ 16:50:14:195 DBG ] Command Line Argument: c++-header
[ 16:50:14:195 DBG ] Command Line Argument: -w
[ 16:50:14:195 DBG ] Command Line Argument: -ferror-limit=1000
[ 16:50:14:195 DBG ] Command Line Argument: -nobuiltininc

I guess this means -std=c++11 never gets sent to clang code completion? Any ideas?

[eranif]

Hi,

Please do an SVN update and re-build codelite.
I added an new checkbox under the "Project -> Code Completion" which enables C++11 by adding the -std=gnu++11

Eran

[CyberRascal]

Hey, thanks for the great support!

That did away with many errors. However, I've still got one (or more after that, lol).

Code: Select all

Undeclared identifier: __float128

__float128 seems to be a builtin type in GCC/G++. Incidentally, this is what I use to compile my program.
I'm not sure why it is visible to clang though - it happens whenever I include a std header.

Arguments to clang:

Code: Select all

[ 21:11:08:442 DBG ] ClangWorkerThread:: processing request 2
[ 21:11:08:442 DBG ] ClangWorkerThread:: found cached TU: (
[ 21:11:08:442 DBG ] Command Line Argument: -I/usr/lib/clang/3.1/include
[ 21:11:08:442 DBG ] Command Line Argument: -I/usr/include
[ 21:11:08:442 DBG ] Command Line Argument: -I/home/me/myproj
[ 21:11:08:442 DBG ] Command Line Argument: -std=gnu++11
[ 21:11:08:442 DBG ] Command Line Argument: -w
[ 21:11:08:442 DBG ] Command Line Argument: -ferror-limit=1000
[ 21:11:08:442 DBG ] Command Line Argument: -nobuiltininc

Seemingly relevant (but possibly irrelevant): /usr/lib/gcc/arch/4.7.0/include seems to be included - might this cause some header to be pulled in that really shouldn't? I see that these paths are set in settings/tags/clang, but emptying the list does nothing - when I restart Codelite, they are there again.

As I said, not sure what might be going on.

Code: Select all

[ 21:00:08:107 DBG ] Settings clang default search paths to:
[ 21:00:08:107 DBG ] /usr/include/c++/4.7.0
[ 21:00:08:108 DBG ] /usr/include/c++/4.7.0/x86_64-unknown-linux-gnu
[ 21:00:08:108 DBG ] /usr/include/c++/4.7.0/backward
[ 21:00:08:108 DBG ] /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
[ 21:00:08:108 DBG ] /usr/local/include
[ 21:00:08:108 DBG ] /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
[ 21:00:08:108 DBG ] /usr/include
[ 21:00:08:117 DBG ] Aborting PCH caching...

Now, I don't want to bother anyone since you do this for free, but I'd appreciate any help

[eranif]

How did;

/usr/lib/clang/3.1/include

got there? did you place them there?

IN general, I am using clang (with C++11 support) without any issues.

The differences that I can see is that I am using G++4.6.3 (Kubuntu 12.04) + I am not using any of the clang include paths

/usr/lib/gcc/arch/4.7.0/include seems to be included - might this cause some header to be pulled in that really shouldn't? I see that these paths are set in settings/tags/clang, but emptying the list does nothing - when I restart Codelite, they are there again.

When codelite "sees" that the list is empty it will place the default headers paths (based on g++ and *not* clang)
To make sure that it will not populate the list on startup, place something there (e.g. /usr/include)

Eran

[CyberRascal]

I put the clang include there because otherwise clang would complain about "no stdarg.h found".

Can you tell me what version of clang you are using for completion?

Keeping the tags/clang/paths list empty doesn't fix anything, sadly.

It might be a problem with GCC 4.7.0 and Clang 3.1 which I am using...

I did find this thread:

http://www.mail-archive.com/gcc-patches ... 31724.html

[eranif]

Clang 3.1 which I am using...

You are missing a point here, codelite does not use *your* clang it uses its own clang (unless you re-built libclang.so by yourself)
codelite is using /usr/lib/codelite/libclang.so which comes with codelite sources

It might be a problem with GCC 4.7.0

This definitely might be the cause of the problem.
Can you try and install GCC 4.6 and update-alternatives to use it instead of 4.7?


On my hand, I will see if I can install GCC 4.7 here and use it for testing purposes

Thanks,
Eran

[CyberRascal]

Oh I see, didn't realize that. Sorry. Still weird though that I get the 'cannot find stdargs.h' error. What include-paths is clang getting on your end?

I haven't ever downgraded anything on arch, so it might take a while, will give it a shot though..