Invalid Diagnostic Tags

EDG 6.6's diagnostic engine groups all "this construct is malformed in a way the front end recognized" diagnostics under a single naming convention: the tag begins with invalid_. Static analysis of the cudafe++ binary recovers 153 distinct invalid_* tags embedded as plain ASCII identifiers in the string pool, making this the single largest coherent diagnostic family that EDG ships. Every reason the parser, semantic analyzer, attribute engine, or template engine can refuse a declaration is named by one of these tags.

This page catalogs all 153 tags grouped by which front-end sub-system raises them. Each invalid_* tag works the same way as the constexpr_* family documented in Constexpr Diagnostic Tags: a stable string identifier keyed into the diagnostic message table, routed to a numeric error code at presentation time. For evaluator-side tags see the constexpr page; for the engine that resolves tag identifiers to message templates see Diagnostics Overview.

Why This Family Matters in Practice

The invalid_* tags are the most frequently suppressed diagnostic class in real CUDA codebases. Three reasons:

1. Microsoft-attribute interop. A surprising fraction of the tag set (16 tags) covers __declspec / C++/CLI / WinRT attribute placement -- code targeting Windows hosts routinely hits these and pragma-suppresses them through --diag_suppress.
2. CUDA-specific atomic intrinsics. The nv_atomic_* family (8 tags) exists only in NVIDIA's fork of EDG and is silently emitted when device-side atomics receive a mismatched size, scope, or memory-order argument. Most user code never trips these, but template-heavy device libraries (cuda::std::atomic_ref) hit them during instantiation and rely on suppression to keep the build clean.
3. Reflection and modules (C++23/26). Tags for ^^ reflection (P2996) and the IFC binary module format (ifc_*) appear as invalid_* rather than as their own family. They fire on toolchain mismatches more often than on user mistakes, so build systems whitelist them.

The result is that the invalid_* family carries the highest "noise-to-signal" ratio of any EDG diagnostic class: most occurrences are not bugs in the user's code, they are signs that the user's code is interacting with a Microsoft, CUDA, or reflection extension whose contract the user did not realize EDG was enforcing.

Where the Tags Come From

The diagnostic engine resolves invalid_* identifiers through the same pipeline as every other EDG tag:

// Conceptual sketch of an emit site inside the declaration parser
emit_diagnostic(
    state,
    "invalid_storage_class_in_for_init",   // tag identifier
    decl_specifier_location,                // source position
    decl_token_text);                       // formatted operand

The tag identifier is then routed through the message-table to:

1. Resolve the canonical numeric error code (the invalid_* family spans codes in the 21--29 range for parse errors, 290--370 for Microsoft attribute checks, 1530--1810 for template-engine checks, and 3120--3290 for the CUDA atomic extensions).
2. Look up the localized message template.
3. Format operands.
4. Possibly chain framing tags (declaration context, attribute context) so the rendered diagnostic includes a "in declaration of X" prefix.

Because the tag is a stable string identifier, EDG can renumber the user-visible error codes without touching the call sites. The tag is the contract between the front-end pass that detected the violation and the diagnostic writer.

Worked Example: Source to Diagnostic

A non-storage-class keyword in a for (init; ...) clause exercises a single tag end-to-end:

for (constexpr int i = 0; i < 10; ++i) { /* ... */ }

constexpr is not one of the storage-class specifiers the standard whitelists for the init-statement. The declaration parser inside sub_5C2D40 flags this and routes through the diagnostic engine:

error #29 [invalid_storage_class_in_for_init]:
    "constexpr" cannot be used as a storage class in a for-init-statement
    for (constexpr int i = 0; i < 10; ++i) {
         ^^^^^^^^^

The numeric #29 is a presentation artifact; the tag carries the actual semantic content and is what --diag_suppress=29 ultimately suppresses.

Grouping Methodology

The 153 tags partition naturally by which front-end pass raises them, with one cross-cutting bucket for Microsoft extensions because those tags fire from several different passes but share a behavioral contract (relax in Microsoft mode, strict otherwise). The groups below mirror the structure of the EDG dispatcher: lexer first, parser next, semantic checks, then specialized engines.

Confidence level for the entire catalog: HIGH. Tag identifiers are present verbatim in the binary; sub-area assignment follows keyword stems and the few cross-references to the front-end functions whose code paths reference them. Exact numeric error codes are MEDIUM confidence -- the binary contains both the strings and the code-to-message routing, but we have not exhaustively traced every tag-to-number edge.

Group 1 -- Lexer and Character-Class Tags (5 tags)

The lowest-level tags: fired during tokenization, before any parsing decisions are made. Each names a class of malformed input character or universal-character-name.

These five exist as a closed set because the lexer is the only sub-system whose input is bytes rather than tokens; once tokenization succeeds, character-class violations cannot recur. See Lexer & Tokenizer for the relevant state machine.

Group 2 -- Parser Structural Tags (11 tags)

Tags raised by the recursive-descent parser when a token appears where the grammar does not allow it. These are typically thrown from the declaration parser (sub_5C2D40 family) or the statement parser entry point.

⚡ QUIRK -- the invalid_declaration umbrella EDG falls back to invalid_declaration whenever the parser hits a more-specific failure path it has not been wired to name. This tag corresponds to error code #29 and is one of the most-suppressed in the entire compiler because it can mean almost anything. Build systems that whitelist it lose precision: a subsequent EDG release that adds a new specific tag will continue routing through invalid_declaration until the new tag becomes available, then silently flip. CUDA code targeting host compilers that use a different grammar for __declspec placement is the canonical case where invalid_declaration fires legitimately as the catch-all.

Group 3 -- Attribute and Microsoft-Attribute Tags (17 tags)

The largest sub-area: 12 of these tags exist solely to police __declspec, [uuid(...)], and the C++11 [[attribute]] syntax. Six more cover generic attribute application rules. The ms_attr_* and *_ms_attr tags fire from sub_5DA210 (the Microsoft attribute parser) and its siblings; the rest fire from the standard-attribute pass in sub_5DBE00.

⚡ QUIRK -- the ms_attr / attribute_ms cross-naming EDG's naming of this sub-family is inconsistent: tags begin either with ms_attr_ (e.g. invalid_ms_attr_name) or end with _ms_attr (e.g. invalid_use_of_ms_attr). The two halves resolve to different message templates with subtly different rendering: the ms_attr_* form takes the attribute name as its primary operand, the *_ms_attr form takes the target (the entity the attribute is being applied to) as its primary operand. The differing word order in the rendered error text breaks any naive grep over the error log -- a user-visible "Microsoft attribute" string can come from either form. This is the most common reason --diag_suppress=N works for one occurrence and not the next: the user picked a number from a *_ms_attr-flavored error and tried to apply it to a ms_attr_*-flavored emit site, which uses a different code.

Group 4 -- Type System Validity Tags (27 tags)

Tags fired by the type checker when a type expression resolves to something the language rules forbid. The largest sub-group inside invalid_* after attributes. Many of these fire during template instantiation and are therefore the dominant cause of "the same template works on GCC but not on EDG-host with CUDA".

Group 5 -- Template and Concept Tags (15 tags)

Tags raised by the template engine during deduction, constraint checking, or specialization matching. These fire from sub_5F8AE0 (template-id resolution), sub_60D940 (concept satisfaction), and the deduction engine.

Group 6 -- Function and Declaration Semantic Tags (16 tags)

Tags raised by the semantic analyzer when a declaration is syntactically well-formed but violates a language rule that depends on context.

Group 7 -- Literal Operator (UDL) and Operator Tags (9 tags)

User-defined literal operators have a tight parameter-list contract. These tags fire during literal-operator declaration parsing.

Group 8 -- Constexpr / Consteval / Constinit Declaration Tags (7 tags)

Companion to the Constexpr Diagnostic Tags page: these tags fire during declaration parsing rather than during evaluation. The constexpr page covers the evaluation-time failures; this group covers the malformed-declaration failures.

⚡ QUIRK -- declaration-time vs. evaluation-time constexpr tags The constexpr_* family (112 tags, see Constexpr Diagnostic Tags) and this 7-tag invalid_constexpr* subset look like duplicates but actually split the work: tags here fire from the declaration parser before evaluation begins, the constexpr_* family fires from the interpreter during evaluation. The cleanest way to tell them apart is the rule about which one fires when the declaration is well-formed but the body fails on every input: that's a constexpr_* evaluator tag, not an invalid_constexpr declaration tag. CUDA's --expt-relaxed-constexpr relaxes the evaluator tags but not these declaration tags -- there is no flag that lets you put a goto into a constexpr function pre-C++23, regardless of the CUDA mode.

Group 9 -- CUDA NVIDIA Atomic Intrinsic Tags (9 tags)

Tags found only in NVIDIA's fork of EDG. These fire when the front end is processing a __nv_atomic_* builtin (the lowering target for cuda::std::atomic_ref and friends) and the argument types or values don't match the intrinsic's contract.

⚡ QUIRK -- nv_atomic_* tags do not honor --diag_suppress cleanly The NVIDIA-specific atomic tags are emitted from a code path that bypasses some of the host EDG diagnostic-suppression machinery. In particular, suppressing the numeric code that one of these tags resolves to can also suppress unrelated host-compiler diagnostics that share the same numeric code through the general "invalid intrinsic argument" message bucket. The workaround in libcudacxx is to suppress at the tag level using #pragma nv_diag_suppress rather than the numeric code -- which works because the tag-keyed pragma form looks up the tag directly. Many cuda::atomic template specializations carry such a pragma at the top of the file for exactly this reason.

Group 10 -- Reflection (P2996) and Module/IFC Tags (12 tags)

Tags fired by the C++26 reflection engine (^^ operator and friends) and the IFC binary-module-format loader. Both are recent additions; the ifc_* family was added in EDG 6.6's modules support.

⚡ QUIRK -- ifc_* tags fire on toolchain mismatch, not on user code The IFC validation tags (invalid_ifc_partition is the exception -- it's a user-syntax tag) fire when the binary-module file itself is malformed, typically because it was produced by a different EDG version than the one reading it. End users never see these in normal builds. They appear when a project uses a precompiled module cache produced by one nvcc release and a different release tries to consume it. --Werror would normally promote these but build systems frequently filter them out specifically because they're not user-actionable. The right fix is rebuilding the module from source, not suppressing the diagnostic.

Group 11 -- Microsoft / C++/CLI / Win32 Compatibility Tags (20 tags)

Tags that exist only because EDG supports Microsoft-flavored C++ (managed ^ handles, __event, __property, MSVC compatibility pragmas). These fire from the C++/CLI front end when input has Microsoft mode enabled but otherwise lie dormant.

Group 12 -- Other / Numerics / Layout (7 tags)

The remainder: tags that don't fit cleanly into a sub-system bucket. Numeric / enumeration / case-value edge cases, miscellaneous IO and address tags, and a few standalone semantic checks.

Per-Group Tag Counts

Sub-family stems that look like overlaps between groups (e.g. invalid_attribute_* could land in Group 3 or Group 11) are resolved by which front-end pass owns the emit site rather than which keyword appears in the tag name. The Microsoft compatibility group (11) owns tags whose semantic content disappears when -mno-microsoft is in effect, even when the keyword stem (invalid_pragma_*) would also fit the attribute or parser groups.

Tag-to-Error-Code Crosswalk (selected)

Confirmed pairings (HIGH confidence -- recovered from cross-references near the emit sites):

Several tags route to the same numeric code (notably the invalid_*_for_literal_operator family all map to a single literal-operator bucket). The tag carries the precise diagnostic context, the code is the user-facing bucket. This is also how --diag_suppress=N can silence multiple distinct tags at once -- which is occasionally what users want and occasionally a foot-gun.

Behavior Under --diag_suppress and --Werror

The invalid_* family's behavior under EDG's two main diagnostic-policy flags is worth calling out because it is the major reason this catalog exists:

• --diag_suppress=N suppresses by numeric code. Because many tags route to the same code, this is broad. Suppressing the literal-operator bucket silences all nine invalid_*_for_literal_operator tags simultaneously. Users frequently want only one of them, but EDG provides no per-tag suppression at the public CLI level.
• --Werror promotes warnings to errors but does not change which tags fire. A tag that is emitted as a warning by default (e.g. invalid_use_of_standalone_ms_attr in Microsoft mode) becomes an error. A tag that does not fire by default (suppressed by language-mode gates) stays silent.
• #pragma nv_diag_suppress <tag> is the NVIDIA fork's tag-keyed suppression form. This works on tag identity and is the only reliable way to suppress one tag without silencing its siblings. Used heavily in libcudacxx for the nv_atomic_* tags.

⚡ QUIRK -- tags fired but not caught by --Werror A small set of invalid_* tags emit as "remark" rather than "warning" -- the diagnostic engine's lowest severity. --Werror only promotes warning to error, not remark. The notable ones are invalid_ifc_position_backtrace_field, invalid_ifc_position_backtrace_pos, and the rest of the _ifc_position_* set: these are emitted as remarks because they indicate a malformed binary module file the compiler is going to fail later anyway. --Werror won't catch them; you have to either inspect the build log manually or use --diag_remark to promote remarks. This is why CI systems that rely solely on --Werror sometimes miss IFC corruption issues until a downstream link or load failure.

Cross-References

• Constexpr Diagnostic Tags -- Sibling diagnostic family, evaluation-time analog of Group 8
• Lexer & Tokenizer -- Where Group 1 character-class tags originate
• Declaration Parser -- Where Groups 2, 6, 7, 8 fire
• Expression Parser -- Where Group 12's miscellaneous expression-level tags fire
• Template Engine -- Group 5's home
• Type System -- The 22 type kinds whose rules Group 4 enforces
• Diagnostics Overview -- Tag-to-message resolution, format specifier handling, SARIF emission
• CUDA Error Catalog -- CUDA-specific overlays for Group 9 and the CUDA-mode behavior of Group 8

Open Followups

• Confirm whether invalid_address_specifier (referenced in Group 12) is actually present in the binary or whether the user's reference was a typo for one of the invalid_attribute_* tags. The string mine yielded 153 matches; the spec called out 150, suggesting three tags are recent additions not yet documented in the source-tree side of EDG.
• Tag-to-emit-site map. For each tag, the address inside the relevant front-end pass that references it. This would tighten the confidence on tag-to-numeric-code routing from MEDIUM to HIGH and let users predict exactly which --diag_suppress numeric codes will catch which tags.
• Cross-reference the nv_atomic_* tags with the libcudacxx source tree to confirm the workaround pragmas listed in the QUIRK callout match what NVIDIA actually ships. Verify whether SM-version gating affects which tags fire (_operation_max_min_float is the candidate).
• Document the per-tag default severity (error / warning / remark). The "fired but not caught by --Werror" QUIRK suggests several tags are remark-by-default; a complete severity table would let users predict which tags need --diag_remark promotion.
• Verify the IFC position tag set against the IFC format specification (P1689) to determine whether any of these tags can ever legitimately fire on user-controllable input as opposed to compiler-toolchain mismatch.