You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
surface: a generated name may not be a C++ keyword
Six sites across four files ran the same character filter -- letters, digits
and `_` survive, everything else becomes `_`, a leading digit gets a `_` --
and none of them asked whether the result is reserved. `default`,
`template`, `operator`, `private` and `union` are valid identifiers to that
filter, and `shaders/default/` is an ordinary name for a shader directory.
Measured: renaming the fixture's `shaders/a` to `shaders/default` makes the
generator write
namespace default {
and the build fails at `expected identifier before 'default'`, inside a
generated file, on a line the author of that directory has never opened.
`surface::identifier` does all three transformations in one place, and a
reserved result gets a TRAILING underscore -- a leading one is itself
reserved at namespace scope, so prefixing would trade one reserved name for
another. Namespace segments in `rules-spirv` and `rules-slang` go through
it, as does `tools-embed`'s accessor name.
The accessor is sanitised where it is EMITTED rather than in each producer.
A rule that builds `item::identifier` from a file stem cannot know it has
produced `my-shader_comp` or `default` until it reaches the one line that
writes the function's name. `accessor_base` and the `_spv` symbols are left
alone: both carry fixed affixes and cannot come out reserved, and routing
them would rename symbols already published.
The fixture could not see any of this: `a` and `b` are ordinary identifiers,
so both filters produce the same file. It gains `shaders/default/`, and CI
asserts the generated interface contains `namespace default_ {`.
0 commit comments