Bilingual post · Post bilíngue


Jump to: English · Português

English {#english}

Nova Arquitetura v2.0.1: A Turning Point

Postman tests in and the broader design rationale in places v2.0.1 inside the classic pipeline:

Lexer → Parser → Semantic → Codegen / Runtime

         ↑

    Unit resolver + ProjectConfig feed real symbols here

Frontend analysis stays in Rust. Library behavior increasingly lives in Pascal RTL shims under rtl/sys/ and third-party .pas trees — the same split Delphi uses.

Why this matters for Horse and CRUD

Your Postman session hits routes compiled from real Horse units on the search path, not a 200-line Rust stub. When Horse adds middleware signatures, you update Pascal sources — the compiler loads them on next run.

Recursive unit loading (blog post 026) builds on this foundation: once paths are honest, dependency graphs follow .pas uses clauses naturally.

Trade-offs we accept

• 
  Requires search paths — missing .dproj falls back to cwd; document paths in examples.


• 
  Parse cost — first load parses units; cache wins on repeat runs within process.


• 
  Not full MSBuild — we read paths, not every Delphi conditional; crabpascal.toml fills gaps.

Migration checklist for your project

1. Add or verify .dproj with DCC_UnitSearchPath
   


2. Mirror paths in crabpascal.toml if you skip .dproj
   


3. Run crab-pascal check — unresolved unit errors should name the missing path


4. Compare run vs build-exe parity (post 040)

v2.0.1 was the line between demo and platform. Everything since — sprints, Mintlify architecture section, honest build — assumes real units.

Related modules in the repo

Trace these files while reading provaram que APIs Horse rodam. Por baixo, isso só funciona porque a v2.0.1 parou de fingir ser interpretador de brinquedo com shims hardcoded infinitos. A virada arquitetural está em .

O problema da v2.0.0: simular tudo

Antes da v2.0.1, complete_runtime.rs tinha uma tabela match function_name crescente — THorse.Get, IntToStr, TJSONObject.Create, sem fim. Cada unit Delphi nova significava mais simulação em Rust, não mais Pascal.

// Anti-padrão que aposentamos

match function_name {

    "THorse.Get" => { /* HTTP improvisado */ },

    "IntToStr" => { /* caso especial */ },

    // ... crescimento ilimitado

}

Isso não escalava e não era compilador de verdade — era interpretador de fantasia Delphi.

Solução v2.0.1: units reais de projetos reais

O pipeline novo lê metadados de projeto Delphi e carrega .pas dos search paths configurados:

programa .dpr

  ↓

.dproj (opcional) → DCC_UnitSearchPath

  ↓

ProjectConfig.find_unit_file("Horse")

  ↓

Parse + executa fontes Horse.pas de verdade

ProjectConfig em src/project_config.rs parseia XML do .dproj:

<DCC_UnitSearchPath>

  examples\crud\modules;

  examples\crud\modules\horse\src;

</DCC_UnitSearchPath>

Paths resolvem relativos ao diretório do projeto, com busca recursiva quando necessário.

Integração no runtime

CompletePascalRuntime aceita config opcional:

pub struct CompletePascalRuntime {

    project_config: Option<ProjectConfig>,

    // ...

}



impl CompletePascalRuntime {

    pub fn with_config(project_config: Option<ProjectConfig>) -> Self { /* ... */ }

}

Carregamento de units saiu de chutes hardcoded:

// Antes: vec!["examples/agenda/Foo.pas", ...]

// Depois:

if let Some(path) = config.find_unit_file(unit_name) {

    self.parse_and_load_unit(path, unit_name)?;

}

main.rs carrega config na subida quando existe .dproj irmão — transparente para crab-pascal run myapp.dpr.

Contexto do compilador em cinco fases

:

Quando unit falha ao resolver, habilite log verbose e imprima paths candidatos — a maioria dos "Horse not found" são DCC_UnitSearchPath mal configurado, não feature faltando no compilador.

Próximo da série

Post 038 — Internals do runtime mergulha em heap, tabelas de métodos virtuais e dispatch de built-ins — a maquinaria que faz OOP Pascal rodar depois que units carregam.

Published on