CDT Indexer is refusing to Index some files [message #1748576] |
Thu, 24 November 2016 16:24 |
Eclipse User |
|
|
|
I have been using Eclipse CDT for some years and there's always been an issue or two which were always a pain in the butt, but the problems that CDT Indexer has gave me in the pass, were without doubt the worse.
Now I have a new issue. It seems that Eclipse CDT is refusing to index some files in my tree and I don't know why. The indexer simply refuses to index them and doesn't tell me why. Because of that, defined classes and namespaces aren't seen in other source files.
i'm using Eclipse Neon.1 (4.6.1) Build ID M20160907-1200
and CDT is 9.1.0.201609121658
Has anyone had a similar issue in the past?
Force an full index refresh inside the project does not help. I'm also unable to replicate the issue in a simple example.
|
|
|
|
Re: CDT Indexer is refusing to Index some files [message #1749460 is a reply to message #1748704] |
Wed, 07 December 2016 02:06 |
Eclipse User |
|
|
|
I'm sorry for the slow answer. I didn't noticed that there was a response to the post.
You asked if the code compiles. Yes it does. GCC does not complain and correctly compiles the code.
Yes, the header directory is in the Indexer includes, as it has always been.
Regarding the specific indications, I created a parser log file for the specific library header.
The log file provided an indication that one of the Included headers was not being indexed. The header file location was provided after the "Unresolved includes (from headers in index):" notation.
These false-negatives are quite problematic because they sometimes induce me in error. They make me look for errors that do not exist and slowdown my speed of development.
BTW, I have updated Eclipse to Neon.2 and CDT to 9.2RC4
The issue still prevails.
[Updated on: Wed, 07 December 2016 02:08] by Moderator Report message to a moderator
|
|
|
Re: CDT Indexer is refusing to Index some files [message #1749461 is a reply to message #1749460] |
Wed, 07 December 2016 02:42 |
David Vavra Messages: 1426 Registered: October 2012 |
Senior Member |
|
|
Don't know what to say. You haven't provided much more information than the original post. Telling us you have an indication but not providing specifics won't get you too far. Not that doing so will guarantee a resolution. It could be a bug.
I haven't had any problems with the Indexer except in specific instances with C+11 std library headers. I suspect it's something in your code that's the trigger.
It's possible to add code that only the Indexer can see which may help.
Surround the code with #ifdef __CDT_PARSER__ ...#endif
https://www.eclipse.org/forums/index.php/t/1068546/
What that code may be depends on the rest of the code. It could be something as simple as defining a macro or a minimal class definition.
If you want, you can file a bug : https://bugs.eclipse.org/bugs/
However, unless there is something you can fix yourself, you won't get much satisfaction.
You will need a small, reproducible example that exhibits the problem. Who knows? In trying to make one you may discover what it is you need to do.
[Updated on: Wed, 07 December 2016 02:47] Report message to a moderator
|
|
|
|
Re: CDT Indexer is refusing to Index some files [message #1749549 is a reply to message #1749464] |
Thu, 08 December 2016 02:51 |
Eclipse User |
|
|
|
OK, this is getting weirder...
I have inspected my code and I was able to remove all of the false error markings.
It seems there was a problem in another header file, along the inclusion tree, which was causing the issue. The thing is, I'm unable to reproduce it in a smaller confined setup :/
For what I can understand, there must be some issues with the indexer when resolving very deep namespaces (ex: A::B::C::D::E::F) and unnamed namespaces. I have some of these in my project.
Because of those false warnings, the indexer was having a weird behaviour, not being able to correctly pin-point the location of declared types.
I will try to continue to see if I'm capable of creating an example. I will then post it here.
|
|
|
|
Re: CDT Indexer is refusing to Index some files [message #1750580 is a reply to message #1749582] |
Fri, 23 December 2016 02:00 |
Eclipse User |
|
|
|
OK, I have some news.
On my chase to try to have an example, I was not completely successfully, but I have found a way to replicate a behaviour which goes on the same line of what I have described previously.
I am able to replicate this weird behaviour.
This issue appears for CDT 9.2 in Eclipse Oxygen.
So, in this case, it seems that the CDT indexer gets confuse when two classes with the same name, are implemented in two different files wherever if they are modules or headers.
How Replicating the bug:
Three files side-by-side in the project root.
mod1.cpp contains:
class Blah{
int x {0};
public:
Blah() = default;
int get(){ return this->x; }
};
int main(){
Blah a;
a.get();
return 0;
}
mod2.cpp contains:
#include "test.hpp"
int main(){
Blah a;
a.get();
a.getVal();
return 0;
}
test.hpp contains:
#ifndef TEST_HPP_
#define TEST_HPP_
class Blah{
int x {0};
public:
Blah() = default;
int getVal(){ return this->x;}
};
#endif /* TEST_HPP_ */
Now, if I add those files to a basic C++ project and Force a rebuild of the project, the indexer will show an error in the source "mod2.cpp" saying that a.get() cannot be resolved.
But then, I modified the test.hpp header, but just adding a single space and saving the file. After saving the file, the indexer will no longer show the error and will indicate that both "getVal()" and "get()" methods are valid for class "Blah"
The following image can provide a visual info of what is going on.
If I force the indexer to rebuild again, the indexer error will show once again. If I again, modify the test.hpp header by adding or removing a single space and then save the file, the issue will again appear.
|
|
|
|
Re: CDT Indexer is refusing to Index some files [message #1750647 is a reply to message #1750646] |
Fri, 23 December 2016 19:19 |
Eclipse User |
|
|
|
Why would it be strange? This is just a simple example.
There is no problem in having two modules that generate two different executables for say, two different targets in a makefile.
Anyway, the indexer should handle this without problem. Not handling it means there is no isolation between the parsed information for each module.
|
|
|
|
Re: CDT Indexer is refusing to Index some files [message #1750655 is a reply to message #1750652] |
Fri, 23 December 2016 21:54 |
Eclipse User |
|
|
|
I understand your point of view and I'm not saying that you are not right. You are.
What I am trying to say is, if the indexer is not isolating each module, then it means it can leak information (maybe also namespace information) from one module to another under weird circumstances.
The issue that I explained previously, may or may not be a consequence of such leakage.
I attempted to fill a bug report but it seems the issue tracker does not allow me to fill bug reports without administration approval.
I do not know if this issue is valid or important enough to even contact an admin to get such permissions...
[Updated on: Fri, 23 December 2016 21:55] by Moderator Report message to a moderator
|
|
|
Re: CDT Indexer is refusing to Index some files [message #1750722 is a reply to message #1750655] |
Tue, 27 December 2016 12:04 |
Eclipse User |
|
|
|
Hello again!
I believe I have isolated the bug that is causing me problems. It has to do with a mix of using a shared_ptr as an object attribute and using friendship declarations.
The code that I used, follows.
For the object.hpp
#ifndef OBJECT_HPP_
#define OBJECT_HPP_
namespace stuff {
class Object{
friend class Builder; // Only connector can instantiate a Builder object.
explicit
Object()
{};
public:
virtual
~Object() = default;
};
}
#endif /* OBJECT_HPP_ */
For the builder.hpp
#ifndef CONNECTOR_HPP_
#define CONNECTOR_HPP_
#include <memory>
#include "object.hpp"
namespace stuff {
class Builder{
public:
enum class OPTIONS : uint32_t{
OPTION_1 = 1,
};
private:
std::shared_ptr<OPTIONS> opts {nullptr};
public:
Builder() = default;
virtual
~Builder() = default;
explicit
Builder(const Builder::OPTIONS& ops)
: opts {std::make_shared<OPTIONS>(ops)}
{}
};
}
#endif /* CONNECTOR_HPP_ */
For the main.hpp
#include <iostream>
#include "builder.hpp"
#include "object.hpp"
using namespace std;
using namespace stuff;
int main() {
Builder c(Builder::OPTIONS::OPTION_1);
return 0;
}
For some reason unknown to me, the indexer fails to index properly the builder.hpp header.
If I force an indexer rebuild, this region of the code Builder c(Builder::OPTIONS::OPTION_1); will be marked as an error, because the indexer is unable to find the symbol OPTION_1
I tracked this issue to the 'shared_ptr' in 'builder.hpp'. It seems that the reason for this behaviour, is in the 'shared_ptr' initialisation. If I remove the 'nullptr' and just let the 'shared_ptr' initialise by itself, this issue will not happen.
I also found out that, if I force an error to occur, for example, by adding 'std::' behind 'nullptr', saving the file, let the indexer point out the error, removing that same 'std::', saving again and letting the indexer work once again, the behaviour will not repeat itself.
The following printscreen may help to see the issue.
[Updated on: Tue, 27 December 2016 19:41] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
Re: CDT Indexer is refusing to Index some files [message #1809533 is a reply to message #1809521] |
Wed, 17 July 2019 15:02 |
David Vavra Messages: 1426 Registered: October 2012 |
Senior Member |
|
|
Is /usr/include/c++/9.1.0/list a file?
It looks like a drectory name.
Most includes have an ext.
Is it for std::list?
Plus there is a discrepancy between what you use as path
and what the indexer reports.
You are saying usr/... And the indexer says /usr/....
There is a difference.
If it really is a file,
try opening it in an editor window and then index it.
The only other suggestion I have is to try to simplify the code
to isolate the problem
[Updated on: Wed, 17 July 2019 21:18] Report message to a moderator
|
|
|
|
Powered by
FUDForum. Page generated in 0.05893 seconds