ShaderCompiler

The aggregate modes in practice

--emit-types writes the reflection types header, which every generated header includes; the types live in the fixed ShaderCompiler namespace, deliberately independent of -n, so headers generated with different data namespaces can be included together.

--emit-sw-generated never fails on unsupported input: shaders outside the transpiler's subset are declined** and simply omitted, and the printed summary lists each one with its reason. It is also the only path that builds stage sources with SOFTWARE_RENDERER defined, see the conditionals below.

--emit-cg is an aggregate for a different reason than the other two: its output could have been two more fields on the per-shader header, but rewriting those headers requires Windows (that is where the DXBC and SPIR-V blobs in them come from), so a Cg regeneration on any other host would silently drop them. A separate header keeps the two independent — a Cg run touches nothing else. Like --emit-sw-generated it never fails on unsupported input: a variant the transform declines is omitted and listed in the printed summary, and the backend then reports that shader as unavailable at load time.

--emit-fixed-function is the opposite: an invalid block is a hard error that fails the whole run, because a block is authored intent, see below.

Top-level directives

Declarations shared by both modes

Custom mode (the default)

No template and no built-in substitutions: user identifiers pass through untouched. Both entry points are required. The body of void vertex() becomes the vertex main() verbatim and writes gl_Position itself. The body of void fragment() is lowered with "out vec4 COLOR;", where COLOR is the fragment output variable itself — undefined until written, with no default and no epilogue, so an early return; is safe. Referencing fragColor anywhere in a .shader file is a parse error — that name does not exist, write COLOR.

Canvas mode (shader_type canvas_item)

Opts into the engine's standard sprite template (InstanceBlock / InstancesBlock and the vTexCoords / vColor / vPaletteOffset varyings) and makes the batched twin available.

void vertex() is optional: the generated main() computes the built-ins as locals, splices the body verbatim, then runs the standard epilogue (gl_Position plus the varying stores). Because of that epilogue, return; inside a canvas vertex() is a parse error. void fragment() is required and enters with COLOR holding the instance color.

A canvas document that references TEXTURE without declaring uTexture gets "uniform sampler2D uTexture;" auto-declared with texture unit 0; an explicit declaration, with or without a texture_unit(N) hint, wins. The four fragment built-ins are the whole set: the names NORMAL, SCREEN_UV, SCREEN_PIXEL_SIZE, TIME, POINT_COORD — and VERTEX, which exists only in the vertex stage — are reported as unsupported rather than silently passed through, in void fragment() and in the shared globals alike.

The template's built-ins are ordinary locals of the generated main(), so redeclaring one in the body is a GLSL redeclaration error. When a canvas document has no void vertex() at all, the vertex stage is the template alone — the shared globals are not emitted into it, since nothing there could reference them.

Variants, conditionals and includes

Reflection must run per variant, so the tool contains a mini preprocessor implementing the object-like subset of the C preprocessor (#define / #undef, #if / #ifdef / #ifndef / #elif / #else / #endif with integer constant expressions). It produces the declaration stream fed to the reflection parser — the emitted sources are not preprocessed output, they keep the original text verbatim with only the variant define and "#line 1" baked at the top. Two rules are special: GL_ES is never predefined (reflection is taken from the desktop GL view) and BATCH_SIZE is symbolic — it evaluates as 1 inside #if expressions but stays symbolic when used as an array size.

Three conditionals are resolved at compile time and therefore never survive into any emitted source:

• "#ifdef VERTEX_STAGE" / "#ifdef FRAGMENT_STAGE" (with an optional "#else") select which stage sees a shared global. They are rarely needed anymore — attributes and varyings have their own keywords, stage-specific helper functions need no guards because unused functions are eliminated per stage, and everything else is harmless when shared.
• "#ifdef SOFTWARE_RENDERER" / "#ifndef SOFTWARE_RENDERER" is resolved when the stage source is built, and only the --emit-sw-generated path builds with it defined. A shader can therefore carry a cheaper CPU variant of an expensive fragment path without changing any other backend's output — see "TexturedBackground.shader", whose software branch approximates pow(distance, 1.5) and drops the per-pixel star field. Wrapped around global-scope varying declarations** it goes one step further and gives the software renderer a different set of varyings: the tool consumes the directive lines while parsing, tags each declaration and re-wraps it per stage, so a conditional there may contain nothing but varying declarations (and no nested directives). "tests/SwVarying.shader" is the worked example — vPos for the shader backends, vRect for the software one.
• #ifdef <VARIANT> on a variant name resolves per variant, in the GLSL stages and inside a fixed_function block alike.

Only those exact #ifdef / #ifndef spellings are recognized: #if defined(...) is not a form any of the three resolvers accepts — for the stage macros it is a hard error, and for SOFTWARE_RENDERER the macro name simply leaks into the emitted source. Every other conditional passes through textually, and nesting works in both directions.

Automatic cleanup passes

The emitted stage sources keep the original text verbatim, but several conservative passes run per stage, in this order:

• Stage conditionals — resolved as described above; no stage macros survive.
• Unused-function elimination — every global function never referenced outside its own definition is removed, iterating to a fixpoint with main() as the root.
• Unused-varying trimming — a varying the fragment stage never reads is removed together with its provably dead vertex-stage stores, or demoted to a plain global when a store has side effects.
• Unused-uniform/block elimination — per-stage dead uniforms, std140 blocks, defines and structs are removed under a hard reflection-preservation rule: a declaration leaves a stage only when the same declaration survives in the other stage, so the merged per-variant reflection is byte-identical before and after the pass.
• Constant folding — literal-only subexpressions inside function bodies are folded with exact GLSL semantics. Global-scope declarations are never touched, which again guarantees reflection stays byte-identical.

Block selection and what gets emitted

A block's parentheses hold its target list:

A block that names a backend — on its own or inside a list — wins over the generic block for it regardless of declaration order**, and every target belongs to exactly one block per file: a target claimed twice is an error whether it was spelled singly or inside a list. The list form is for the case where two consoles reach an effect with literally the same code; when the bodies genuinely differ, they stay separate blocks. Capabilities are then checked against the intersection of the listed targets.

Today Colorized.shader, FrozenMask.shader, PartialWhiteMask.shader and the two background shaders carry a shared void fixed_function(pvr, psp) block (the two no-combiner tiers) plus a void fixed_function(gx) one, and Transition.shader carries a void fixed_function(pvr) block plus a shared void fixed_function(gx, psp) one (the two 16-vertex strip scratches); everything else has a single generic block — which is the norm, since a program with no block at all for a backend is skipped at runtime there.

The --emit-fixed-function mode transpiles the applicable block of every program variant — the block is preprocessed once per variant with the variant define baked in, exactly like the fragment stage — into the body of a "void <Program>[_<VARIANT>]_Effect(EffectContext&)" C++ function, and collects them into one aggregate header per backend with a FixedFunctionGeneratedEffects[] table of

{ program, variant, usesOffsetColor, requirements, intrinsic, &function }

entries, keyed by the true (program, variant) identity the loaders plumb in with ShaderProgram::SetProgramIdentity() — no shader name is ever matched in a backend. An entry carries either a function or an intrinsic, never both. Programs without an applicable block are absent from the table and skipped at runtime with a one-time warning. The including device file supplies the concrete EffectContext through a using alias before the include; the generated header is otherwise self-contained, carrying its own small ff vector runtime so that FixedFunctionPass.h stays the only contract between the generator and the backends.

Two fields are computed statically per (program, variant) while the body is emitted:

• usesOffsetColor — whether any reachable p.offset_color = ... assignment exists, because the PVR needs it when compiling the base polygon header (specular enable is per program, not per pass). It is derived from the selected body, so it can differ per backend: PartialWhiteMask is true on the PVR and the PSP, which lift the sprite with an offset colour, and false on the GX, which uses the combiner's x2 output scale instead.

• requirements — a FixedFunctionRequirements bitmask of the optional EffectContext facilities the function can ever call: NeedsTexelStep (texel_size() / has_texel_size()), NeedsUniforms (has_uniform() / uniform_vec2/vec4()), NeedsStripBuilder (strip_*() / submit_strip[_shaded]()) and NeedsQuadAxes (quad_origin() / quad_axis_x/y()). The backends' Dispatch gates the matching per-draw context setup on these bits and skips the rest; because the bits come from the same analysis that emitted the calls, this can never change what a function submits.

  Byte-identical bodies are deduplicated.** Emitted bodies deliberately carry no program name, so batched twins and palette variants — which differ only in the dispatch loop's instance decoding, not in their pass code — come out identical and collapse into one function, named after its first occurrence and preceded by a provenance comment: a from <file>:<block> line naming where the body came from, plus a // Shared by: line listing every (program, variant) that points at it, each bracketed with its own origin when it came from a different file. Today's 39 table rows contain 6 intrinsic bindings and 33 effect rows, which collapse to 10 emitted functions on each of the three backends.

Pipeline bindings

A block whose sole statement is pipeline <name>; does not describe passes at all: it binds the program to a backend pipeline stage that consumes an engine data structure, and the table entry carries the FixedFunctionIntrinsic value instead of a function pointer. Anything else in such a block is an error — a block either describes passes or names a stage.

The geometry-synthesized quad effects are not intrinsics — the transition iris and the warped background are ordinary transpiled blocks built on the strip builder.

Passes and their fields

pass p; declares a FixedFunctionPass local starting from the engine defaults (a plain modulated sprite pass with the material's own blending). It takes no initializer, each pass needs its own statement, the fields are write-only — reading one back is an error — and only plain = assignment is accepted.

The two GX-only presets need the programmable TEV combiner — the CLX2 can modulate a texel by the vertex colour and add an offset colour, and that is its whole vocabulary, while the GE has five fixed texture functions over one texel and the fragment colour — so using them outside a block targeting the GX alone is a hard error rather than a silently wrong console frame. A generic block is rejected too, because it is transpiled for every backend, and so is a target list such as void fixed_function(gx, psp), because the GE it also serves cannot express them.

The two output scales are the mirror image: the GE has no scale stage at all, so they are rejected for every block the psp target can reach — a psp block, a target list naming psp, and a generic one alike. Unlike the GX-only presets this is not a per-block capability — the PVR silently ignores p.tev, so a pvr block may keep using one — but a shared block using an output scale would be honoured by only some of the consoles it serves, which is precisely the "silently depends on one console's feature" case these checks exist to prevent. On the no-combiner tiers a boost is expressed as passes instead: Colorized.shader splits its multiplier into up to three additive passes in its shared pvr, psp block.

p.offset_color is a third capability gap, and the one place where the answer is mechanism rather than policy: the GE has no post-texture additive term either (GU_TFX_ADD adds the texel to the fragment colour, not a third value), so the GU's EffectContext::SubmitQuad expands a pass carrying an offset colour into the modulated sprite plus an additive silhouette pass over it. With a = texel.a * color.a the pair produces dst*(1 - a) + a*texel*color.rgb + a*offset — term for term what the PVR's single specular-enabled draw produces — and collapses to ONE draw when color.rgb is zero, which is the mask/outline/shield idiom where the offset colour is the effect. Because the expansion lives in the backend, every generic** block that writes an offset colour keeps working unchanged on all three consoles; the GX does the analogous thing by reinterpreting the pass as its silhouette form.

Built-ins

The portable core is valid in every block. The extended vocabulary is reserved for blocks that NAME their backends (a single target or a target list — either way every backend it serves is spelled out), so a shared description can never silently depend on one console's geometry synthesis.

The submission and strip calls are statements, not values; using one inside an expression is an error. The strip scratch is a backend capability — 8 vertices on the PVR and 16 on the GX and the GU, which both prefer fewer, longer primitives (on the GE every strip costs a draw call of its own) — and a literal vertex index outside 0 to capacity-1, or a literal count outside 3 to capacity, is a hard error, because at runtime an out-of-range index is dropped and an oversized count clamped, which would silently draw the wrong geometry. A block naming several targets is held to the minimum of their capacities, so void fixed_function(pvr, gx) gets the PVR's 8. Computed indices and counts stay unchecked.

Capability rules for a target list

A block that names several backends is validated against the intersection of what they can do — never against the backend whose header happens to be generated at that moment, which would accept a body that is silently wrong on the other backends the same block serves.

Each diagnostic names which of the block's own targets rejects the feature, so the fix — splitting the list back into separate blocks — is obvious from the message alone.

Statements and expressions

The block body is a plain statement list over a deliberately small type system: float, int, bool, vec2, vec3, vec4 and the opaque pass.

• Statements — local declarations (with initializers and comma-separated declarators), pass declarations, plain and compound assignment (=, +=, -=, *=, /=), prefix and postfix ++ / -- on an int variable, if / else, C-style for whose init declares or assigns an int counter and whose condition is a bool, braced blocks with their own scope, and the submission/strip calls above. Only those can stand alone as a statement.
• Operators — + - * / on numeric operands, with a scalar broadcasting over a vector and mismatched vector widths rejected; % on int only; < > <= >= on numeric scalars; == and != on numeric scalars or bools; && || ^^ on bools; unary - on any numeric scalar or vector, unary ! on a bool; and the ternary ?:, whose condition must be bool and whose branches must have the same type.
• Functions — min / max taking (float, float), (int, int), (vecN, vecN) or (vecN, float); clamp and mix in the corresponding 3-argument shapes; ceil / floor on a float or a vector; abs / sqrt / sin / cos on a float; the conversions float(x) / int(x); and vec2 / vec3 / vec4 constructors as either a single-scalar splat or any scalar/vector mix whose components sum to the target width.
• Swizzles — single components in any spelling (xyzw, rgba, stpq), plus .xy, .zw, .xyz and .yzw for reading. Only a single component can be assigned; a multi-component swizzle store is rejected, because the emitted vector types expose multi-swizzles as read-only accessors.

Explicitly not part of the grammar, each with its own error: while, do, switch, return, break, continue, discard, arrays and indexing, unary ~, the remaining compound assignments (%=, &=, |=, ^=, <<=, >>=), assignments nested inside expressions, initializing or assigning a pass as a value, and redeclaring COLOR or ctx. A blend/tev preset name cannot be used as a variable either.

Error behaviour

Unlike the software transpiler, which declines shaders outside its subset — they simply stay absent from its table — a fixed_function block is authored intent: anything outside the grammar is a hard error with the offending file and line, and it fails the whole GenerateAll.ps1 run, so a mistake surfaces on the dev machine instead of silently dropping a console effect. Common ones:

• unknown pass field '.<name>' (fields: color, offset_color, screen_offset, blend, tev, luma_gain)
• unknown blend mode '<name>' (expected MATERIAL, ADD, OPAQUE or ALPHA), and the matching unknown tev preset ...
• TINT_MIX or LUMA_RAMP reported as a GX-only capability — they need the programmable TEV combiner, so they are accepted only in a block targeting gx alone. A target list gets the reason spelled out: LUMA_RAMP is a GX-only capability - ... only available in a fixed_function(gx) block, not in one that also targets psp
• MODULATE_X2 has no GE equivalent - the PSP's texture environment has no combiner output scale, so it cannot be expressed for the psp target (...) — emitted for every block the psp target reaches: a psp block, a target list naming psp (where the message reads for the psp target this block also names*, and fires even while another backend's header is being written), and a generic one
• A builtin of the extended vocabulary reported as only available in a backend-specific block — generic blocks keep the portable quad-only core
• vertex index 12 is outside the pvr strip builder's capacity of 8 vertices (the same message says 16 for gx and psp; a target list is held to the smallest capacity among its targets and says so)
• pass fields cannot be read back (they are write-only descriptors), COLOR is read-only, a pass variable itself cannot be assigned (assign its fields)
• 'while' is not part of the fixed_function grammar (statements: pass/local declarations, assignments, if/else, for, submit_quad)
• "pipeline <name>;" must be the only statement of the fixed_function block and unknown pipeline "<name>" (known: tile_map_mesh, lighting_combine, line_strip_mesh)
• duplicate "void fixed_function(<target>)" block - the <target> target is already claimed by the block on line <N> (and duplicate "void fixed_function()" block - the generic block is already declared on line <N>) — one target belongs to one block, however it was spelled
• unknown fixed_function target "<name>" (expected pvr, gx, psp, a comma-separated list of them, or empty parentheses for the generic block), duplicate target "<name>" in the fixed_function target list and empty fixed_function target list entry (a trailing comma)

Worked examples

• "WhiteMask.shader" — the minimal shape: one silhouette pass whose colour comes from the offset colour. PartialWhiteMask.shader is the same effect split by capability, contrasting the offset-colour lift (one shared void fixed_function(pvr, psp) block — neither console has an output scale, and both deliver an offset colour) against the combiner's x2 output scale (gx). The smallest example of the list form: two lines of pass code that used to exist twice.
• "Outline.shader" — the ring is just a loop: a nested for over the eight neighbours, each an offset silhouette guarded by has_texel_size(), then the sprite itself. An idiom rather than a keyword, which is the whole point of the language being this small.
• "Colorized.shader" — a runtime-dependent pass count on the no-combiner tiers (the multiplier split into up to three additive passes in one shared void fixed_function(pvr, psp) block, since neither tier can carry a multiplier above 1.0) versus a single MODULATE_X4 pass on the GX.
• "FrozenMask.shader" — the consoles reaching the same GLSL mix() differently, and the clearest illustration of why a target list is a capability statement: the PVR and the PSP share a block because neither can do per-texel arithmetic, so both settle for a constant ice tone, while the gx block picks the tone per texel with LUMA_RAMP and luma_gain = 2.6, reproducing the shader's tone for every luminance.
• "Transition.shader" — geometry synthesis: the iris fan built from quad_origin() / quad_axis_x/y() and shaded strips, 32 segments in the pvr block and 64 with a three-band eased edge in one shared void fixed_function(gx, psp) block. The iris needs no combiner at all — only geometry and per-vertex colours — so what decides the split is the strip scratch: the GX and the GU both take the 10-vertex strip that walks all five radii in ONE draw, and the PVR's 8 vertices cannot hold it. It is also the one shader whose list pairs gx with psp rather than pvr with psp.
• "Include/TexturedBackgroundWarp.inc" — the warp rebuild, shared by both background shaders and all three backends: the band geometry uses only extended vocabulary that every console implements the same way, so the include is literally the same code everywhere. Only the horizon-tint delivery differs, switched by a WARP_TINT_IN_VERTEX_COLOR macro the including block defines before the #include — set by the gx block alone, which is why the other two consoles need nothing but a shared void fixed_function(pvr, psp) block around the bare #include, and also the general idiom for specializing a shared include per backend.

Installing

Point the editor's extensions directory at the in-tree copy, then restart Visual Studio Code (or run Developer: Reload Window) so the new directory is scanned:

# Linux / macOS
ln -sfn "$PWD/Sources/Utilities/VSCodeExtension" ~/.vscode/extensions/death-shader

rem Windows, from an elevated prompt (a directory junction needs no elevation on recent builds)
mklink /D "%USERPROFILE%\.vscode\extensions\death-shader" "%CD%\Sources\Utilities\VSCodeExtension"

A symlink is preferable to a copy: the extension then tracks the repository, so a change to the language and a change to its editor support land together. To develop the extension itself, open "Sources/Utilities/VSCodeExtension" as a folder and press F5 — the bundled ".vscode/launch.json" starts an extension-host window with the repository root already open. For distribution outside the repository, npx @vscode/vsce package produces a .vsix; that is the only workflow that needs Node installed.

How it finds the tool

The executable is resolved in this order, the first hit winning:

1. The deathShader.compilerPath setting, if set — absolute, or relative to the workspace folder (never relative to the editor's working directory).
2. Build outputs inside the workspace: "Sources/Utilities/ShaderCompiler/<x64|ARM64EC|Win32>/<Release|Debug>/" (the MSBuild project's output, and where GenerateAll.ps1 expects it), then any CMake tree at the repository root whose directory name starts with build or cmake-build, then "out/build/<preset>/" for the Visual Studio CMake integration.
3. ShaderCompiler on PATH.

A status-bar item on the right names the executable in use, or warns when none was found; clicking it prints the resolved path. Without an executable the extension still works — it falls back to the checks in the second diagnostic layer — but nothing that needs to parse or transform a shader is available.

Highlighting, completion and navigation

The grammar is self-contained, so it does not depend on any other GLSL extension being installed. On top of ordinary GLSL it scopes the language's own vocabulary: the top-level directives, the uniform ... : hint list, the three entry points, the canvas built-ins, the compile-time stage macros, and the whole fixed-function DSL as its own region (pass, pipeline, the submit_* calls, the pass fields and their MATERIAL/ADD/... and MODULATE/LUMA_RAMP/... values, the optional context facilities). Constructs the language rejects are scoped as errors, so a colour theme paints them as mistakes before the compiler ever runs: fragColor, a #version line, an unsupported canvas built-in, an unknown render mode or uniform hint, and a stage macro used in #if defined(...) / #elif / #define / #undef.

Completion is chosen from the cursor's context rather than offered as one flat list:

The mode-awareness is real, not cosmetic: the canvas built-ins are only offered under shader_type canvas_item (in custom mode TEXTURE is an ordinary user identifier, so offering it would be wrong), VERTEX only inside vertex(), and TEXTURE / PALETTE_OFFSET only outside it.

Hovering a directive, built-in, uniform hint, pass field or context facility shows what the compiler does with it — the same rules this page documents. Hovering a name the file declares shows its declaration line. Ctrl-clicking an #include path opens the file, go-to-definition works on any name declared in the document, and the outline (Ctrl+Shift+O) lists the programs, the batched twin, the variants, the uniform blocks, the uniforms with their texture units, the varyings, the attributes, the helper functions and the entry points with their fixed_function target lists.

Snippets cover the whole-file skeletons (shader-custom, shader-canvas) and every directive, entry point and fixed_function shape.

Diagnostics

Two independent layers, both on by default:

1. The compiler. ShaderCompiler <file> --check is run over the document; it parses and reflects the input and writes nothing. Its stderr is parsed in all three shapes described under the command-line reference — "<file>:<line>: error: <message>", "<file>: error: <message>" and a bare "error: <message>" — including Windows paths whose drive letter contains a colon. Anything the parser, the reflection or an emitter reports therefore reaches the editor verbatim.
2. Checks the extension can prove on its own, so a file still gets feedback with no executable around: a missing or duplicate program, a missing void fragment() (or void vertex() in custom mode), a directive written before program, batched without shader_type canvas_item, a #version line, a reference to fragColor, a stage macro in an illegal preprocessor form, a return; inside a canvas-mode vertex(), and an unsupported canvas built-in. Each one is a hard error this page documents. Set deathShader.validate.builtinChecks to false to leave diagnostics entirely to the compiler.

The second layer knows when not to fire, which matters more than what it catches. Every structural check stands down for a file containing #include, because the includes are expanded textually before parsing and may legitimately carry the program directive or an entry point — exactly the shape "LightingMesh.shader" has. The canvas-only rules are skipped in custom mode, and a mention inside a comment never reports.

Validation runs on save, and on open. Setting deathShader.validate.run to onType validates while typing, debounced by deathShader.validate.delay. Since the compiler reads from disk, a dirty buffer is then written to a temporary copy first: next to the original when the document has #include lines (include paths resolve relative to the input file, so a copy elsewhere would not find them) and in the OS temporary directory otherwise. Those copies carry a ".vscode-death-shader-tmp." infix and are deleted immediately; leftovers from a killed session are swept up on activation. Nothing else in the tree is ever written.

Transform previews

The five inspection dumps are exposed as commands — right-click a .shader file, or use the command palette. All of them print to stdout and write nothing, so they are safe to run on a buffer at any time:

Each opens the transform in a preview beside the source, so the GLSL and what a given backend actually receives can be read side by side. Show Resolved ShaderCompiler Path and Validate Current File round out the command set.

Settings

The extension declares itself unsupported in untrusted workspaces, since diagnostics and the previews execute a binary from the workspace.

Keeping it in step with the tool

.inc is registered for the language as well, since the shader includes in "Sources/Shaders/Include" use that extension. Such a file is treated as an include fragment: it is pasted textually into some .shader file, so it has no program directive, no entry points and no shader_type of its own. The structural checks therefore stand down for it (the ones that do not depend on file structure still apply), and because its shader mode cannot be known from the file alone, completion there offers the canvas built-ins regardless of mode instead of guessing.

The language vocabulary lives in exactly one place, "src/language.js", which both the completion and the hovers read. When this page gains a directive, a render_mode, a pass field or a context facility, add it there too — and to "syntaxes/deathshader.tmLanguage.json" if it needs its own colour. The test suite asserts the closed sets against what the parser accepts (the six render modes, the three fixed-function targets, the six pass fields, the four blend modes, the six tev presets, the three pipeline intrinsics), so a set that drifts out of step fails a test rather than silently offering a stale list.

node test/run-tests.js && node test/run-provider-tests.js

Both suites are dependency-free and also run under any other plain JS engine, gjs included. "run-tests.js" covers the text analysis — comment stripping, the document scan, the cursor contexts, the three diagnostic shapes, and every check together with the cases that must not fire. "run-provider-tests.js" drives the real editor providers against a mock vscode API wrapped in a proxy that throws on any member it does not define, so a mistyped API name fails in the test rather than in the editor.