Skip to content

OMIT/COMPILE phase 2: define-driven conditional evaluation + editor gray-out decoration #270

Description

@msarson

Follow-up to #255 (core shipped in ba530e1: unconditional OMIT invisible to diagnostics + refs/counts, rename still included, COMPILE polarity fixed).

Two deferred phases from the decided semantics table:

1. Conditional OMIT/COMPILE evaluation (server substrate)

OMIT('***', _DEBUG_) / COMPILE('***', TraceFiles) are conservatively treated as LIVE today (defines aren''t evaluated). The substrate step: plumb the active configuration''s defines from the solution layer (.cwproj) into OmitCompileDetector so conditional blocks resolve to omitted/live per the ACTIVE build config. Gate behind bidirectional-pin fixtures — evaluating defines changes rename/refs visibility silently if wrong. Note the equate-vs-define distinction and _WIDTH32_-style built-ins.

2. Gray-out decoration (client phase)

The primary UX in every C++ IDE for inactive regions. Client already has decorator infrastructure to extend (UnreachableCodeDecorator). Server can ship the omitted ranges (from findDirectiveBlocks, OMIT-only per the #255 polarity rule) via a custom notification, client renders editorUnnecessaryCode-style dimming.

Both phases inherit the #255 test harness (OmitCompile.PipelineVisibility.test.ts).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions