I had a long look at the remaining changes. (InProcLevel, ...)
As far as I can see, they are dealing with {$ELSE} (and only $ELSE)?
If they have any other effects, without $ELSE (or even without any $IFDEF) then let me know.
Currently I am inclined not to merge them.
They break currently working functionality.
procedure foo;
begin
{$IFDEF A}
try
{$ELSE}
//
{$ENDIF}
// ...
{$IFDEF A}
finally
end;
{$ELSE}
//
{$ENDIF}
end;
"try" can no longer be folded.
I have not looked for further examples, but I am sure, I could find them. Equally I am sure that even if you fix this one, there will be others, and some will always be broken.
It is (IMHO) in the nature of ifdef, that (at least without codetools) it is impossible to interpret them correct. If you add code trying, you will simply change one error for another, but pay the price of added complexity.
For example what if instead of $ELSE, the code is {$IFDEF foo} .. {$ENDIF}{$IFDEF opposit_of_foo} .. {$ENDIF}. Or 3 or more consecutive IFDEF, of which you can not detect, if there will be exactly one, zero or one, one or more, zero or more used?
I also think that given the fact that it can always only address a subset of ifdef variations, and that there is no way to predict if users will have those variations or others, the overhead this code adds (in resource usage) is not justified.
-----------------
The only way I can thing that would improve ifdef handling, is ignoring inactive code (like the lowlighting does).
Everything else will be changing one problem for another problem, and which problem is the bigger issue will be each users personal view.
To ignore inactive code codetools is needed. Codetools can not be used inside the HL. It be possible to try a new module to archive ifdef handling (like the lowlighting, or extending that).
But this in definitely not part of this thread. (it is too big a topic of its own)
-----------------
Appart from this a few notes on the implementation.
Those criteria had no part in the decision, any changes to them will not affect the decision.
They are whatever I picked up yet, and probably incomplete
1) It appears that it is limited to 32 nest levels of ifdef, and then what? (32 bits in cardinal)
2) Smart idea to use strings. saving some memory, as copy on write means several ranges can share one string.
2a)
while L < EndLevelIfDef+1 do begin
SetLength(DepthProcsMade, L+1);
Set the length before the loop.
This code will reallocate the memory over and over. That can cause major slowdown.