[PATCH] Wrong search order for #include_next

[Neil Booth]

Alexey Neyman wrote:-

> The problem arises when an #include_next directive is used from a file that 
> was included in quotes itself. In this case, this means:
> 
> tst.c: #include <limits.h>
> $GCCINC/limits.h: #include "syslimits.h"
> $GCCINC/syslimits.h: #include_next <limits.h>
> 
> The problem is that the paths supplied to the cpp_set_include_chains() routine 
> are not inserted into the directory hash. Therefore, when syslimits.h is 
> included, a new cpp_dir entry is created and prepended to the quote_include 
> list by the make_cpp_dir() routine. The resulting search path list looks 
> like:
> 
> [$GCCINC] --> [/usr/local/include] --> [$GCCINC] --> [/usr/include]
> 
> The syslimits.h file is found in the 1st entry ($GCCINC) and retains a pointer 
> to that entry in its 'dir' field. When the `#include_next <limits.h>' is 
> attempted, the search starts at the dir->next directory, which 
> is /usr/local/include in this example. Therefore, the <limits.h> is found in 
> the 3rd entry, which is again $GCCINC.

This is intended behaviour.  Once you have #include "" the include chain
is prepended with the current directory, and searching starts there.
Since that is where in the include chain it was found, #include_next
correctly starts after that point.

The real bug is the use of "" includes in what appears to be a system
header.  limits.h should angled includes.

Neil.