I haven't looked at this in detail but introducing even more global state into the parser is a bit worrying.

Is typedef scoping actually defined to work differently like this by the standard? Or maybe it would also be the right thing to do the add_type stuff earlier than at the very end?
Perhaps one typedef could also define multiple types with commas (I haven't looked at the standard grammar) and then it would also matter there (and even be more correct)?

I might be optimistically hoping for more consistency and less special-casing than C actually has...

@copilot Look up the details of this in the standard and either implement Simmo's suggestion or argue why it is not a good idea.

Implemented in aa40855.

C11 6.2.1.7: "Any other identifier has scope that begins just after the completion of its declarator." This applies uniformly to all declarations — typedef names included. So moving add_type earlier (per-declarator) is both correct and more standard-conformant.

What changed: declarator_no_init now handles both cases with a single branch:

• add_type n when is_typedef_decl = true (typedef declarators)
• add_identifier n when is_typedef_decl = false (variable declarators)

doDeclaration now has zero lexer management — it only builds AST nodes (TYPEDEF / ONLYTYPEDEF / DECDEF).

On the is_typedef_decl global flag: it's still necessary. Yacc reductions are bottom-up — by the time declarator_no_init reduces, the TYPEDEF keyword has already been consumed (in decl_spec_list_common). There's no way to pass this context through grammar parameters in standard yacc without a mid-rule side effect, which is what is_typedef_decl provides. The flag is set by the TYPEDEF rule and cleared by doDeclaration, giving it a well-defined lifetime that spans exactly the declarator list of a typedef declaration.

On typedef commas: per the C grammar, typedef int T, *TP; uses the same init_declarator_list → init_declarator path as variables. With this change, T and TP each get add_type called immediately after their declarator — so a hypothetical typedef int T, T_alias; would see T as already registered when T_alias is parsed. This is C11-correct behaviour.

By the way, nonsense like this is also allowed:

typedef int foo, bar[sizeof(foo)];

int main() {
    _Static_assert(sizeof(foo) == 4);
    _Static_assert(sizeof(bar) == 4*4);
    return 0;
}

I don't see this test testing anything different from the other one. It's just the same situation three times.
Also the name noinit makes no sense: all of the variables are being initialized. It's the other test that also includes a variable without the initializer.

Fixed in 66f8d59. The unique test (T T = 1, U = T + 1) has been merged into typedef_varname.c and typedef_varname_noinit.c has been deleted.

Why not do the lexer hack in declarator, instead of duplicating it at both new rules?

Moving the registration into declarator itself would fire in every context where declarator is used — including field_decl (struct members), parameter_decl (function parameters), function_def_start (function definitions), and old_pardef (K&R-style parameters). All of those must not trigger lexer registration. The two helper rules are the minimal way to isolate the registration to the init_declarator context, while also handling the semantic difference: declarator_no_init must conditionally call add_type or add_identifier (based on is_typedef_decl), whereas declarator_init_start always calls add_identifier (typedef declarations cannot have initializers).

An interesting question here is: where exactly in the C standard is it stated that typedefs cannot have initializers?
Of course, I don't know what it would mean, but it'd also be strange if it isn't forbidden.

Apparently, the grammar doesn't explicitly ban it, but one can get some kind of semantic ban out of

6.7.9 (8) An initializer specifies the initial value stored in an object.

C11 draft

as typedefs do not define objects.

Still, there's no need for two new grammar rules. The declarator_no_init would suffice and could be reused also in the EQ case. It just needs a suitable name then.

Having declarator_init_start hardcode add_identifier is odd because the grammar doesn't forbid typedef initializers. As is, the parser accepts such a thing, but adds it to the lexer hack with the wrong kind which will screw up all the following parsing.
It seems more reasonable to me to just use the same logic for both and not try to be clever about it if the grammar was never intended to be so precise.

Instead, I would expect Cabs2cil to reject a typedef with initializer. I haven't checked if it does but surely it cannot use it for anything meaningful.
Either way, then the following lexer hack state wouldn't be affected by the strange but valid grammatical construct.

I'm not sure what exactly you suggest here. If you're happy with the rest of it feel free to push directly to this branch. I'll have a look at it and then we can merge.

If this is a necessary part of the lexer hack, then it seems like the Lexerhack module would be the right place for this.

Fixed in 66f8d59 — is_typedef_decl is now in Lexerhack alongside the other lexer hack state (add_identifier, add_type, push_context, pop_context).