Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Clang CC on CentOS 7.3
sodev:
Looks like i have been a little bit too lazy, i relied on svn to display these indexdb files as unrevisioned to spot them, too bad some directories had wildcard ignores, so i was wrong, i'm not missing any indexdb files, each project has one, so thats not the issue :D. Search paths are also not the problem, i have files where boost does get picked up and get auto-completed, and every project includes boost by the very same absolute path.
So i took a closer look at the debug messages, and it looks like all my error messages are the same:
--- Code: ---+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/ia32intrin.h to errorIncludes, scope: /my_path/my_header.h
[snip]
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/ia32intrin.h to errorIncludes, scope: /my_path/my_header.h
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/xmmintrin.h to errorIncludes, scope: /my_path/my_header.h
[snip]
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/xmmintrin.h to errorIncludes, scope: /my_path/my_header.h
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h to errorIncludes, scope: /my_path/my_header.h
[snip]
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h to errorIncludes, scope: /my_path/my_header.h
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/adxintrin.h to errorIncludes, scope: /my_path/my_header.h
[snip]
Visit include statement /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h
+++ Inserting error at 13,10
Visit include statement /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/xmmintrin.h
+++ Inserting error at 13,10
Visit include statement /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/immintrin.h
No warnings or errors for this include file
Visit include statement /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/adxintrin.h
+++ Inserting error at 13,10
--- End code ---
In the terminal attached to the codeblocks process i can see clang spills out error messages about undeclared identifier mostly. I verified by example that whenever i open a file that produces these messages, code completion is dead in that file. Files that produce only warnings like unused parameters, type conversion and whatever do have a working code completion.
The second issue i have in some files is that the diagnostics marks some headers with an error like this:
--- Code: ---#include <cstdint>
#include <type_traits>
#include <map>
#include <set>
#include <sstream>
#include <string>
#include <vector>
#include <boost/optional.hpp>
Errors present
#include <boost/shared_ptr.hpp>
#include <boost/scoped_ptr.hpp>
--- End code ---
I can't say for sure if that happens only or always with files that produce the error messages above, but in some examples this was the case.
Playing around with the CC i discovered the following things:
* Using the context menu action "Open include file" on #include statements more or less randomly doesn't work the first time, i have to click on the very same line twice in a row to open the include file
* Clicking in the method body for the first time selects the scope and function in the toolbar, however when opening the function combobox it only contains this very function and the scope name on top. Clicking on it a second time populates this combobox with (almost, see next point) all methods and removes the scope
* The method combobox never contains any constructor or destructor, clicking on the body of any of these unselects everything in the toolbar
* The function "Goto declaration" doesn't work when i click on the method name in the implementation file of that method, only when i click on that methode name in a different file that calls this method. However "Find implementation" on the method name in the header file of that method works, so basically i can switch from the header to the implementation but not the reverse way
--- Quote from: yvesdm3000 on January 19, 2017, 07:55:39 am ---Also be aware, you are trying Clang for code completion, but under the hood you are also using Clang as a kind-of compiler so in theory the code should meet the criteria to be compiled using Clang. I know my daytime-work-project isn't, but the parts I work in are fine (and includes boost).
--- End quote ---
I don't understand what you mean with this, my project gets compiled with gcc only.
yvesdm3000:
--- Quote from: sodev on January 19, 2017, 10:48:58 pm ---Looks like i have been a little bit too lazy, i relied on svn to display these indexdb files as unrevisioned to spot them, too bad some directories had wildcard ignores, so i was wrong, i'm not missing any indexdb files, each project has one, so thats not the issue :D.
--- End quote ---
Good, something I don't have to look into then.
--- Quote --- Search paths are also not the problem, i have files where boost does get picked up and get auto-completed, and every project includes boost by the very same absolute path.
So i took a closer look at the debug messages, and it looks like all my error messages are the same:
--- Code: ---+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/ia32intrin.h to errorIncludes, scope: /my_path/my_header.h
[snip]
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/ia32intrin.h to errorIncludes, scope: /my_path/my_header.h
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/xmmintrin.h to errorIncludes, scope: /my_path/my_header.h
[snip]
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/xmmintrin.h to errorIncludes, scope: /my_path/my_header.h
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h to errorIncludes, scope: /my_path/my_header.h
[snip]
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h to errorIncludes, scope: /my_path/my_header.h
+++ Adding /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/adxintrin.h to errorIncludes, scope: /my_path/my_header.h
[snip]
Visit include statement /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h
+++ Inserting error at 13,10
Visit include statement /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/xmmintrin.h
+++ Inserting error at 13,10
Visit include statement /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/immintrin.h
No warnings or errors for this include file
Visit include statement /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/adxintrin.h
+++ Inserting error at 13,10
--- End code ---
--- End quote ---
OK this is debug output mostly from one of the latest features where a header that contains errors will result in a diagnostic error where the #include statement is. This way, when an error is really triggered by this file, you can spot the source of the error more easily.
--- Quote ---In the terminal attached to the codeblocks process i can see clang spills out error messages about undeclared identifier mostly. I verified by example that whenever i open a file that produces these messages, code completion is dead in that file. Files that produce only warnings like unused parameters, type conversion and whatever do have a working code completion.
The second issue i have in some files is that the diagnostics marks some headers with an error like this:
--- Code: ---#include <cstdint>
#include <type_traits>
#include <map>
#include <set>
#include <sstream>
#include <string>
#include <vector>
#include <boost/optional.hpp>
Errors present
#include <boost/shared_ptr.hpp>
#include <boost/scoped_ptr.hpp>
--- End code ---
--- End quote ---
Although it mostly works, after using this a bit more extensively, I did notice some false positives e.g. the include file is marked with errors, I did not find errors in it. It's the next issue I'm about to fix.
--- Quote ---Playing around with the CC i discovered the following things:
* Using the context menu action "Open include file" on #include statements more or less randomly doesn't work the first time, i have to click on the very same line twice in a row to open the include file
--- End quote ---
Yep, I also noticed this. It's somewhere on the list to be fixed.
--- Quote ---
--- Quote from: yvesdm3000 on January 19, 2017, 07:55:39 am ---Also be aware, you are trying Clang for code completion, but under the hood you are also using Clang as a kind-of compiler so in theory the code should meet the criteria to be compiled using Clang. I know my daytime-work-project isn't, but the parts I work in are fine (and includes boost).
--- End quote ---
I don't understand what you mean with this, my project gets compiled with gcc only.
--- End quote ---
It means that this plugin is based on Clang and under-the-hood your project is being compiled using clang, but only the early stages of compilation, just enough so that an AST tree is created to perform code-completion and diagnostics on it, no executable output.
Your intrinsics-problem is probably because clang can't compile it and gcc can. It's one of the downsides of using Clang for this without an immediate solution altough the Clang developers try to be compatible with gcc as much as they can.
Yves
oBFusCATed:
yvesdm3000: Isn't clang working in a mode where it is tolerant to errors as much as possible?
yvesdm3000:
--- Quote from: oBFusCATed on January 20, 2017, 08:41:58 pm ---yvesdm3000: Isn't clang working in a mode where it is tolerant to errors as much as possible?
--- End quote ---
"As much as possible" --> Yes, but it remains in the first place a compiler. The C::B built-in code-completion parser is probably better at it: it can just skip what looks like a function, a declaration or anything it doesn't know about. Clang will require knowledge on everything to build its AST tree for the compiler part, even if it's only needed for diagnostics or making things pretty...
Yves
yvesdm3000:
I just fixed the "Update parser when typing" setting, it seems it wasnn't implemented properly.
I also moved the setting to the 'Diagnostics'-tab since it really only has an effect on diagnostics (and also for goto-implementation things). For CC a reparse is needed in about 90% of the cases anyway since CC is about modifying code and Clang will implicitly do that for you anyway...
Yves
Navigation
[0] Message Index
[*] Previous page
Go to full version