Code Review from my AI Buddy for the compiler

[stvowi]

I reviewed the unleashedpascal/compiler source. Since the repo is a fork of Free Pascal (37 MB, ~27,000 files), I focused the review on the actual fork-specific delta — using git history to find the fork point, then reviewing the diff for the ~28 most heavily modified core compiler files (covering ~25,000 of the ~26,300 changed lines), where all of Unleashed Pascal's new language features live.

The review found 24 actionable issues, including:

1 Critical: PreInc/PreDec can read through an already-released temp on complex operands (e.g. PreInc(arr[idx()])), a genuine use-after-release bug that can silently corrupt results.

7 High-severity issues, e.g. embed T; never rejects a flexible-array-member record (silent memory-layout corruption), array/tuple equality re-evaluating side-effecting operands multiple times, procvar devirtualization lacking a dominance check (can call the wrong function), autofree/defer crashing the compiler inside a unit's initialization section, and $''' interpolated triple-quote strings not being rejected as documented.

1 medium-high issue: undocumented &=/|= operators silently active in every language mode, a backward-compatibility hazard.

8 medium and 6 low severity issues covering match, for parallel, generics, string interpolation, and compiler options.

The report also documents ~20 higher-risk areas that were specifically checked and found correct — including the project's own two flagged risk areas (FPC_UNLEASHED/FPC_OBJFPC exclusivity and default modeswitch wiring) — so it's clear what was verified rather than skipped.

Each finding includes the exact file/function, a description of why it's a bug, severity, and a suggested fix, with links into the repository. The full report has been saved to your Unleashed Pascal project and shared above.

Unleashed Pascal Compiler — Code Review.md

[fibodevy]

Now do the same report for objfpc. FPC has over 1700 open issues, 17 of which are currently open by me. You could write a book about the bugs in FPC.

I checked that first "Critical" one and for the life of me I can't produce the corrupted code it describes - every case it warns about gives the correct result. Could you help me out and post a program that actually breaks? The report also thinks create_normal_temp frees the slot immediately. It doesn't - it's the standard idiom used all over stock FPC, including in the very branch the report calls "correct".

The only finding that caught my interest is embed + FAM. I'll look into that later.

So a review like this has low value. Especially since when I fed your report to another AI, it told me the report is worthless, wrong, and that it doesn't understand the compiler's API. Maybe the two of them should just talk to each other.

I'd rather have classic issues: post the code, describe what's wrong, and let me compile it and see it with my own eyes.

Funny detail: my AI says your AI contradicts itself. The report praises the PostInc/PostDec path of the same function as the "correct" one, but that path does exactly what the report calls a use-after-release: create_normal_temp(valtmp) followed by a read of valtmp on the next line. Same ordering, one branch is a critical bug and the other is the reference implementation. The semantics are spelled out in ncgbas.pas right above the codegen: "release_to_normal means that the temp will be freed the next time it's used" - so the read after it is the intended last use, not a stale slot. Stock FPC has done it this way for over a decade, e.g. the power-of-2 division lowering in nmat.pas: create_normal_temp(resulttemp) immediately followed by ctemprefnode.create(resulttemp).