Bugs in IDE when trying to follow includes

[MichaelT]

I found that the IDE fails miserably when the code ends up in a neverending loop (while working with includes)

I have included a small project that shows how this happens. You should be able to open it just fine, but when
editing the file (like the 'win.c') the IDE tries to update what it knows about the files. Then .. Boom!

I believe the fault is in the defines, I suspect the IDE doesn't care that much about if something like:

#ifndef __DOH__
#define __DOH__

...

#pragma message ("Doh!")

#endif //__DOH__


is actually set.

I should also add that this source I have included, is a terrible piece of coding. But, this is an issue regardless.
This doesn't happen in any of the other compilers I tried it on (Borland, Visual studio (many versions), Watcom .. even )

The other problem I have noticed (although I don't classify this as a bug per-se)
is that doing something like this:

#include "..\some_backward_path\my_header.h"

prevents the IDE from finding the file, or even open it by right clicking on it.
It goes without saying that this header won't end up in the project files either.

I hope this is of some help to you Pelle, I know you're busy but it would be great if you
could have a look at it.

Oh, and I used the latest version of PellesC.

Update: I debugged it and traced it down to a stack overflow.. If it is of any help.

Best wishes//

Michael

[Pelle]

In version 6.50 (RC) I added a cache to the file dependency scanner, since the old (simpler) approach could scan the same include file more than once (for different source files, etc.).
In older versions a circular dependency was handled by the simpler approach (I think; not checked, since it doesn't really matter anymore), and the initial idea was that the new cache should handle seeing the same file again (not much of a cache if it didn't...). The problem here is that this circular dependency happens before the IDE has a chance to add everything to the cache. Should be fixed in 6.50, RC4.