Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[expr.prim.id.dtor] Comment in example reflects lexing misunderstanding #2630

Closed
Eelis opened this issue Jan 1, 2019 · 3 comments · Fixed by #2633
Closed

[expr.prim.id.dtor] Comment in example reflects lexing misunderstanding #2630

Eelis opened this issue Jan 1, 2019 · 3 comments · Fixed by #2633

Comments

@Eelis
Copy link
Contributor

Eelis commented Jan 1, 2019 •
edited

The example in [expr.prim.id.dtor]/3 shows the following line of code:

0.T::~T(); // error: 0. is a floating-point literal ([lex.fcon])

However, contrary to what the comment suggests, I believe 0. does not appear as a floating-point literal on this line. I believe that what really appears on this line is the pp-number token 0.T (which is not a valid floating literal token).

A very similar case is described in [lex.pptoken]/4:

The program fragment 0xe+foo is parsed as a preprocessing number token (one that is not a valid floating or integer literal token)"
@Eelis Eelis mentioned this issue Jan 1, 2019
Closed
@jensmaurer
Copy link
Member

It seems this is a floating-point literal "0." with a ud-suffix "T" [lex.ext], which happens not to exist. At least that's what gcc tells me, and it seems a reasonable outcome.

@Eelis
Copy link
Contributor Author

Eelis commented Jan 1, 2019

Ah, but if you agree that the 0.T (with the T) is a user-defined-floating-literal, then you should also agree that it's misleading for the comment to suggest that 0. (without the T) on the line is a floating-point literal, because in that case it's actually merely a partial token, and only complete tokens are turned into literals.

@Eelis
Copy link
Contributor Author

Eelis commented Jan 1, 2019 •
edited

I stumbled on this when working on syntax highlighting in cxxdraft-htmlgen. If I lex according to the rules, then on the

0.T::~T(); // error: 0. is a floating-point literal ([lex.fcon])

line, 0.T would be highlighted as a pp-number token. But that looks super contradictory, because then the coloring says that 0.T is the token (which is actually the truth), while the comment talks as though 0. is the token (which is because the comment is confused about lexing).

Eelis added a commit to Eelis/draft that referenced this issue Jan 1, 2019
@Eelis
[expr.prim.id.dtor] Fix comment in example.
87472cf 
In translation phase 3, the "0.T" in the line of code is parsed as a (single) preprocessing-token.

In phase 7, this preprocessing token is converted into a user-defined-floating-literal whose ud-suffix component is "T".

At no point is the "0." partial token a floating-point literal. At most, it is the fractional-constant component in a bigger user-defined-floating-literal token.

Fixes cplusplus#2630.
@Eelis Eelis mentioned this issue Jan 1, 2019
Merged
Eelis added a commit to Eelis/draft that referenced this issue Jan 2, 2019
@Eelis
[expr.prim.id.dtor] Fix comment in example.
84c1d20 
In translation phase 3, the "0.T" in the line of code is parsed as a (single) preprocessing-token.

In phase 7, this preprocessing token is converted into a user-defined-floating-literal whose ud-suffix component is "T".

At no point is the "0." partial token a floating-point literal. At most, it is the fractional-constant component in a bigger user-defined-floating-literal token.

Fixes cplusplus#2630.
zygoloid pushed a commit that referenced this issue Jan 19, 2019
@Eelis @zygoloid
[expr.prim.id.dtor] Fix comment in example.
d426489 
In translation phase 3, the "0.T" in the line of code is parsed as a (single) preprocessing-token.

In phase 7, this preprocessing token is converted into a user-defined-floating-literal whose ud-suffix component is "T".

At no point is the "0." partial token a floating-point literal. At most, it is the fractional-constant component in a bigger user-defined-floating-literal token.

Fixes #2630.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[expr.prim.id.dtor] Fix comment in example. Eelis/draft
2 participants
@Eelis @jensmaurer