Community
Participate
Working Groups
Build ID: M20060921-0945 Steps To Reproduce: 1. If you have more than one header file of the same name under the project root, the OpenIncludeAction will put them all in a list dialog and ask you to pick a file. 2. That's normally OK, but if only one of those files is in an include path then you shouldn't get the dialog at all. It should just open that file. More information: The problem is that OpenIncludeAction looks in system include directories and if not found just searches the whole project. The attached patch checks in the user include paths if not found in the system include paths, and then falls back to the whole project if still not found.
Created attachment 59929 [details] patch file.
Good catch! Thanks for the patch, I applied it to HEAD.
There is another problem with this if there is a header of the same name in both the user and system include paths. The wrong file can be opened. There needs to be a check for the type of include I believe.
Created attachment 61322 [details] another patch to correct search order The previous patch was not quite correct. This patch amends its behavior (it can be applied on top and is not a replacement). The current behavior doesn't distinguish #include <...> from #include "...", and always searches system directories first, so it can find the incorrect version of a header (e.g. when the user has an override). A test is, add a stddef.h file to a project include directory and have a source file with: #include "stddef.h" This should find the version in the project, not the one in the compiler headers or C library.
While we are at it, the directory of the current file is also part of the "..." search path, right? Could you update the patch to handle this case, too?
Never mind, I did it myself. Please verify. Thanks!
Sorry, I missed your last question. I think searching the current directory for "..." includes is okay (and matches the scanner behavior).
