Rule 2.2

Chapter 2, Sources of the surface Test

A compiler-internal name (§2.1) must not be authorable. It must not be declared in the ambient library, as a name, as a signature or an overload of an allowed name, or as a member of an allowed type. It must not be given a row of §9.3, under its own id or under any other spelling of the same thing.

The rule text and the parts under it are the compiler's own English, as the design document writes them.

Rationale

an internal helper is a contract between two passes, and an author who can write it can also write it wrong, with no specification to say what wrong means.

Derives from

the same section of PR #166, written on the f64FromParts case (§2.4).

How it is verified

Checked by a test. A test, a gate script or a CI workflow names this rule, and the traceability check fails when a file listed below stops naming it.

Where the rule says the compiler enforces it:

surface-names.test.ts (no pre-emit intrinsic id is declared or listed), which asserts that every id of PRE_EMIT_INTRINSICS other than the type name f64 is neither declared in SHADE_DTS nor a row of TYPESHADE_EXTENSIONS;
the same test (reports an internal helper by name when one reaches the surface), for the sentence a stray declaration gets;
the same test (the front end resolves no pre-emit id as a builtin), for the call route, since resolveMathFn in src/compiler/ts/math-alias.ts resolves an alias only when isKnownIntrinsic accepts its id, exempting f32, atan2, and mod, none of which is pre-emit, so f64Parts(x) in a shader is TS8004 Unknown function;
the same test’s first case, which catches a generated backend name that is declared, as a stray;
the same test (the f64 family declares only the constructor forms WGSL gives the type it stands in for), for the overload route, which pins every declared signature of f64 to one argument and every signature of vec2f64, vec3f64, and vec4f64 to WGSL’s vector constructor forms (a splat, N components, or a narrower f64 vector plus components);
that same case, which reports f64(hi: f32, lo: f32) appended to the library;
the same test (the compiler refuses a second argument to f64), for the call route of the same overload, TS8019 f64() expects 1 argument.;
the call route of the IR builder’s .swizzle(), which no call reaches by its name since proposal 0008: v.swizzle("yxz") is TS8022, a member the vector does not have, which names the member it is written as, v.yxz, pinned by src/compiler/ts/swizzle-random.test.ts;
review under §2.1’s definition (Rule 9.8), since a name that denotes an internal representation under an id outside PRE_EMIT_INTRINSICS passes every case of the test once it has a row.

The files that verify it at commit 26de7be8, each at the first line that names the rule:

Explained in

The sections of the surface document that explain this rule, at commit 26de7be8:

§17 What a for loop may say, and what it is told

Error codes that enforce it

The diagnostic codes the rule names under Enforced by, or whose registry text names the rule:

TS8004 UNKNOWN_FN: A call to a function the file neither declares nor imports.
TS8019 ARITY_MISMATCH: Wrong number of arguments, elements, or fields at a call or constructor site.
TS8022 UNKNOWN_NAME: Reference to a name TypeShade cannot resolve (identifier, struct field, or struct shape) that is not a function call (UNKNOWN_FN) or a type name (UNKNOWN_TYPE), in a body a call lowers or in one no call lowers; a name the library declares for TypeScript's own use (Object, Math, Symbol), or the file declares as an enum, a namespace, a class or a type, read as a value says what it is.

Source

The rule at commit 26de7be8:

docs/language-design.md:101 (the design document)
reqs/rules/RULE-0202.md (its traceability item)

Edit this page Report a problem