I'd like to work on this issue. Thoughts so far:

• What should happen when the entry rule does not consume any input, like the one in the ?
• What about guard conditions in parser rules? These might get arbitrary complex, and I would find it easier to assert for now that those can be fulfilled sometimes.
• For a rule B that depends on an optional rule A like B: a1=A a2=A; B itself should not need not be marked as completely optional, right? After all, if A would always consume input, then so would B.

My two cents:

• A rule marked as entry should be excluded from this validation: you usually want an empty file to be valid.
• I'd already raise an error if a rule can potentially not consume any input, which means you don't have to care about guard conditions. If you encounter an alternative, check whether any of the alternatives is potentially empty.
• When calling other rules, I'd assume that they do consume input, so that counts as being non-empty.
• I would also count actions like {MyType} as being non-empty. Actually we could offer a code action as quick fix that adds an action to enforce the rule to be valid despite consuming no tokens.

* I would also count actions like `{MyType}` as being non-empty. Actually we could offer a code action as quick fix that adds an action to enforce the rule to be valid despite consuming no tokens.

So to clarify, this grammar would be valid, right?

grammar HelloWorld

interface Empty {};

entry Model:
    Emptyness;
// Action in a parser rule that consumes nothing
Emptyness: {Empty};

hidden terminal WS: /\s+/;

hidden terminal ML_COMMENT: /\/\*[\s\S]*?\*\//;
hidden terminal SL_COMMENT: /\/\/[^\n\r]*/;

Also, what about fragments? Should optionality be checked for them, too?

So to clarify, this grammar would be valid, right?

It would be helpful if that works, but I'm not sure whether it's problematic for the parser.

Also, what about fragments? Should optionality be checked for them, too?

No, a fragment should be allowed to consume no tokens. When calling a fragment rule, treat its content as if it was part of the calling rule.

OK. I've changed the validation to reflect these cases, and to fix false-positive errors with alternative groups.