Skip to content

[temp.res.general] Fix misleading example related to syntax errors #6577

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

Eisenwave
Copy link
Member

The use of the word "may" suggests that an implementation isn't required to diagnose +; if it's in a template, but this is not true. Diagnostics are always required for syntax errors.

As you can see, a syntax error inevitably "bubbles upwards" in the grammar, and also means that any containing template isn't a template in the first place. If there is no containing template, and there isn't even a valid translation-unit, then diagnostics are required because syntax errors fall under the umbrella of diagnosable rules.

Unless "no diagnostic required" was explicitly stated, the following applies:

[...] if a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.

- [intro.compliance.general] p2.3

@Eisenwave
Copy link
Member Author

Eisenwave commented Jul 26, 2025

@jensmaurer thoughts? Does CWG need to see this or am I simply right or wrong on this?

The question boils down to: do we require diagnostics for token soup in templates?

@jensmaurer
Copy link
Member

It is my understanding that the standard wishes to support implementations that stash away a token stream (e.g. based on matching braces) and do not form an AST while parsing a template definition. I believe that, at some point in the past, MSVC was such an implementation.

I agree that the grammar presentation is not amenable to this view, but repairing this is probably a very large effort. Given that all implementations are now, in fact, using an AST representation during template parsing, maybe we can tighten the rules here and actually make +; ill-formed in template definitions. I would like to see a normative change here.

Additional considerations: The C++ grammar is not context-free and there is a possibility that instantiation actually changes the AST slightly (as specified; maybe not as implemented). For example, a "T" template parameter is a type-name, but might (does it?) become a class-name during instantiation. We're not very clear on what happens during instantiation anyway. (We have "typename" and "template" prefixes and various scattered rules to prevent large-scale changes to the AST during instantiation.)

In short, disallowing token-stream implementations should be in a paper and should clearly lay out where the new boundary for required vs. optional diagnostics for the template definition is, for example by amending the IFNDR rule for uninstantiated template definitions to refer to "anything that matches the grammar, but cannot be successfully instantiated" or similar.

@Eisenwave
Copy link
Member Author

Alright, I may write a paper that addresses this problem at some point.

@t3nsor
Copy link
Contributor

t3nsor commented Jul 26, 2025

In the current wording, the real normative issue here is that once you put

template<class T> class X {
  void g(T t) {
    +;
  }
};

somewhere in your program, it nullifies the need for the implementation to issue any diagnostics, even for syntax errors that are inside some unrelated non-templated entity. But, somehow, if you instantiate X, then the IFNDR goes away: the +; has to be diagnosed and so do syntax errors elsewhere in the program. Very odd.

If we said that the above template is unspeciformed instead of IFNDR, that would partially solve the problem, because IFNDR trumps all other rules requiring diagnostics but unspeciformed presumably would not have that effect. Then, it would be clear that the failure of the program to be valid C++ according to the grammar is diagnosable (since that's a rule about the template itself, not about the instantiations of the template).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants