|
wowlib 0.0.0
Read & write World of Warcraft client files — a C++26 core
|
Binding-language identities welder's core does not name. More...
#include <welder/vocabulary.hpp>Go to the source code of this file.
Namespaces | |
| namespace | wowlib |
| namespace | wowlib::lang |
Macros | |
| #define | WOWLIB_CS_FAMILY_SURFACE |
| The C# rod's family-surface opt-in, spellable in every build. | |
Variables | |
| constexpr welder::lang | wowlib::lang::Cs {welder::user_lang<0>} |
| C#/.NET — the welder-csharp rod's identity (user-range slot 0), respelled for wowlib's annotation sites (mark::only, mark::exclude, weld_as). | |
Binding-language identities welder's core does not name.
welder's language value space is open: indices 0–15 belong to the languages welder ships (welder::lang::py, welder::lang::lua), 16–31 are the user range an out-of-tree rod mints its identity from. The welder-csharp rod claims user slot 0 (WELDER_CSHARP_LANG_SLOT, default 0); wowlib respells that same identity here so annotation sites in core headers never include the rod's headers — the rod is only fetched on WOWLIB_BUILD_CSHARP configures, while these headers must parse in every build.
Definition in file lang.hpp.
| #define WOWLIB_CS_FAMILY_SURFACE |
The C# rod's family-surface opt-in, spellable in every build.
[[=welder::rods::csharp::family_surface]] on a welded *Base opts its family into the rod-synthesized version-agnostic surface — but the marker TYPE lives in the rod, which only WOWLIB_BUILD_CSHARP configures fetch, while these headers must parse in every build. So the annotation hides behind this macro: on C# configures CMake defines WOWLIB_CSHARP_ROD tree-wide (every TU of a build must agree on a class's annotation list — gcc-16 reads annotations off the DEFINING declaration only), the rod's marks header is on every include path, and the macro expands to the mark; everywhere else it expands to nothing and the annotation never exists. The trailing comma rides inside the macro so the empty expansion leaves a well-formed annotation list.