Restore XE3 support in V8? Measured: about 10 small changes

[TetzkatLipHoka]

The README points XE3-XE8 users to the V7.6.x line, which no longer receives fixes (and the current V7_stable tip actually no longer compiles on XE3 either, see below). Out of curiosity I measured what V8 master really needs to compile on XE3 - the answer is surprisingly little, so I'd like to ask whether you would accept a PR restoring XE3 as the minimum supported version (it is exactly the boundary your own version fence in the sources enforces: {$if CompilerVersion < 24}{$MESSAGE FATAL ...}).

Verified on a real XE3 installation: after the changes below, all 19 units compile with XE3 dcc32 and dcc64, and a runtime smoke test passes. Delphi 10 Seattle through 13.1 compile unchanged before and after (Win32 and Win64, full test suite still green).

The four barriers, measured:

1. Ungated {$LEGACYIFEND ON} directives. Counter-intuitively, XE3 accepts mixed $IF..$ENDIF / $IFDEF..$IFEND closers by default, but {$LEGACYIFEND ON} (which XE3 already knows) switches it into a strict pairing mode - so these directives are the sole cause of the E2029 cascade on XE3. Fix: gate them with {$IF CompilerVersion >= 25}. This is also what broke XE3 on the V7_stable tip after the last release.
2. [] empty dynamic array literals / + array concatenation (XE7+): three call sites, replaced by nil / SetLength. No behavior change on any version.
3. System.NetEncoding (XE7+): used for HTML escaping in the export; needs a small fallback for older versions (either a tiny escape helper or a gated uses).
4. The V8 alias re-export block in VirtualTrees.pas triggers an internal compiler error (F2084 URW1147) on XE3. Isolated repro: a 66-line unit containing only the alias block ICEs; the reproduction is symbol-table sensitive. Deterministic workaround: gate the convenience alias block with {$IF CompilerVersion >= 25} - XE3 consumers then simply add VirtualTrees.Types to their uses clause.

XE2 and older stay out of reach for structural reasons (record helper for enum types in VirtualTrees.Types requires XE3+), which matches the README pointing XE2 users to a separate fork.

If you are interested I'll submit this as a PR (roughly 10 touch points, no behavior change for currently supported versions). If XE support is out of scope for V8 as a policy decision, that's fine too - then this issue can simply serve as documentation of what it would take.

🤖 Generated with Claude Code

[TetzkatLipHoka]

One more thought on what this would mean for the README's version matrix:

If XE3 support lands in V8, the line "V7.6.x for Delphi XE3 to XE8" becomes obsolete - V8 would simply cover XE3+, and the V7 line (which no longer compiles on XE3 at its current tip anyway) could retire for good.

The remaining two pointers below it are effectively dead ends today:

• The XE2 fork (Fr0sT-Brutal/VirtualTreeView_mod) had its last push in August 2023 and is hundreds of commits behind - it never received the V7/V8 fixes.
• V5.5.3 for Delphi 7 to XE2 is a 2016-era code base.

As a replacement I can offer my maintained fork branch, which carries current V8 master backported to Delphi 7-13.1 including all recent fixes (it is the code base the fixes in #1381-#1392 were developed and tested on, with a 10-compiler build matrix and the DUnitX suite green from Delphi 7 upwards):

https://github.com/TetzkatLipHoka/Virtual-TreeView/tree/v8-delphi7-to-13

So the whole block could shrink to something like:

V8 for RAD Studio XE3 to 13 (this repository)
V8 backport for Delphi 7 to 13.1: TetzkatLipHoka/Virtual-TreeView, branch v8-delphi7-to-13

Entirely your call of course - happy to include the README change in the XE3 PR if you want it.

🤖 Generated with Claude Code