Community
Participate
Working Groups
Whenever the indexer is running, the file is in a state where there could be false errors and warnings. One example of that is when you create a hello world project, there will be errors (ProblemBinding) until the indexer job has completed. This is especially bad if you rebuild the index on a big project and start opening files while it's indexing.
One possible solution is to expedite indexing of the file opened in the active editor. This would also solve bug 248853.
I'm not sure that solution is sufficient or that I understand it correctly. If I have my hello world file opened after the project is created, even if it starts indexing that file first, it will still need to index iostream, etc. That takes a while and there will be ProblemBinding errors until it completes.
(In reply to comment #2) One way to avoid showing bogus errors is to prohibit checkers from running on files that have unindexed includes.
(In reply to comment #3) > (In reply to comment #2) > One way to avoid showing bogus errors is to prohibit checkers from running on > files that have unindexed includes. That should be applied with moderation, at the very least there should be a preference. It is not uncommon for big projects that some headers are unavailable. For example remote projects or generated headers. If a project configured on 90% right it shouldn't prevent static analysis features.
Some checkers do not need indexed headers at all. For example pattern matching checkers like assignment in condition or fall-through case. If only affect checkers that do use index. For semantic checkers is it actually beneficial not to run at all if includes are not resolved - because it will be rather bad if it runs in this case.
I observe something that looks like this bug immediately when creating projects. Specifically, I have eclipse-cpp-indigo-SR1, and when I create new "Hello World C++ project", I immegiately see semantic error on 'std', 'cout' and 'endl'. Then, indexing starts, and after it is done, the markers disappear. Seems like Codan should not run before indexer in that case as well.
Created attachment 208983 [details] Don't run checkers if indexer is busy (In reply to comment #3) > (In reply to comment #2) > > One way to avoid showing bogus errors is to prohibit checkers from running on > files that have unindexed includes. Based on Andrew's comment and the fact that we'd have to check if specific variants of headers (bug 197989) are indexed, do you think this is still the right approach? I assume we'd have to call IASTPreprocessorIncludeStatement.getLoadedVersions() but it is marked @noreference which is not ideal. I tried the other approach of not running index-based checkers while the indexer is running and it seems to work. When the indexer finishes, the editor reconciles and the checkers are executed. I haven't tested it for very long though.
With (In reply to comment #7) > Created attachment 208983 [details] > Don't run checkers if indexer is busy My comment is not on this change, it sounds like it might be a worthy approach. I just want to mention that with the new scanner discovery (bug 290631) a new Hello World project won't need to run its own scanner discovery, it will be available from global provider. When it runs for the first time, it will send notification to the indexer which also can reduce waiting. Correct me if I am wrong, but I believe currently there is an artificial delay before indexer starts to allow scanner discovery to complete.
*** Bug 373705 has been marked as a duplicate of this bug. ***
I'm very tempted to import this patch into our product CDT fork. Is there any issues with this patch that make it not worthy to be included in main CDT?
(In reply to comment #10) > I'm very tempted to import this patch into our product CDT fork. Is there any > issues with this patch that make it not worthy to be included in main CDT? I haven't tested it in a production environment yet. There's also some investigation left to be done. I'm not sure if it's possible for checkers to run with an incomplete (maybe even absent) index between the creation of the project and when the indexer job starts. This is definitely something I want to look at for Juno.
(In reply to comment #10) > I'm very tempted to import this patch into our product CDT fork. Is there any > issues with this patch that make it not worthy to be included in main CDT? I doubt if disablement of checkers whenever indexer is active is going to create a good user experience. On a large project it's likely that the indexer is updating something that does not affect the code in the active editor.
(In reply to comment #12) > I doubt if disablement of checkers whenever indexer is active is going to > create a good user experience. On a large project it's likely that the indexer > is updating something that does not affect the code in the active editor. My primary concern is that there's plenty of false-positives when a new project is introduced to the workspace - it may scare the new users.
(In reply to comment #13) > My primary concern is that there's plenty of false-positives when a new project > is introduced to the workspace - it may scare the new users. It is a valid concern, but it probably requires a solution that distinguishes this situation from regular incremental updates of the index.
We can extend semantics of ASTTranslationUnit.isBasedOnIncompleteIndex method to cover a situation when during parsing some include file could not be found in index but is present in the file system and is resolvable through include path. This would take care of the situation when some of the needed header files have not been indexed yet.
