Skip to content

Inconsistencies in comments for ill-formed/undefined behavior examples #3126

Closed
@burblebee

Description

@burblebee

We're inconsistent in how we format/word comments in examples for ill-formed and undefined behavior code. The following cases show a few of the variations used:

utilities.tex:any_cast<string&>(y);                       // error; cannot
g<int>(0);        // error, substituting parameter type instantiates \tcode{A<int>}
S<char> s1;                     // error: no matching constructor
template<> enum A<char>::E : char { echar };        // ill-formed, \tcode{A<char>::E} was instantiated
struct Inner2;                // ill-formed, no diagnostic required
// ill-formed, no diagnostic required: the two expressions are functionally equivalent but not equivalent
void A<Y>::B<double>::mf2() { }       // ill-formed; \tcode{B<double>} is specialized but
template<class T> void f(T::R);         // ill-formed (no diagnostic required), attempt to declare
p->x.j = 99;                            // undefined: modifies a const subobject
int m = g(false);   // undefined behavior due to access of \tcode{x.n} outside its lifetime
C().C::~C();      // undefined behavior: temporary of type \tcode{C} destroyed twice
pb->f();          // undefined behavior, lifetime of \tcode{*pb} has ended

Suggestion: Change all to either of the following as appropriate:

  // ill-formed, no diagnostic required: <explanation>
  // error: <explanation>
  // undefined behavior: <explanation>

where : <explanation> can be omitted if it is clear from the surrounding text.

This does not apply in compatibility.tex, where we should stick with:
f(u8"text"); // ill-formed; previously well-formed

Metadata

Metadata

Assignees

Labels

bigAn issue causing a large set of changes, scattered across most of the text.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions