This is an archive of the discontinued LLVM Phabricator instance.

Handle interactions between reserved identifier and user-defined suffixes
ClosedPublic

Authored by serge-sans-paille on Jun 15 2021, 8:05 AM.

Details

Summary

According to https://eel.is/c++draft/over.literal

double operator""_Bq(long double); OK: does not use the reserved identifier _­Bq ([lex.name])
double operator"" _Bq(long double);
ill-formed, no diagnostic required: uses the reserved identifier _­Bq ([lex.name])

Obey that rule by keeping track of the operator literal name status wrt. leading whitespace.

Fix: https://bugs.llvm.org/show_bug.cgi?id=50644

Diff Detail

Event Timeline

serge-sans-paille requested review of this revision.Jun 15 2021, 8:05 AM
Herald added a project: Restricted Project. · View Herald Transcript
aaron.ballman added inline comments.Jun 15 2021, 12:18 PM
clang/include/clang/Basic/IdentifierTable.h
124 ↗(On Diff #352146)

I'm on the fence about adding "Leading" to the variable and function names as well. I figure the "leading" makes it clear that we're talking about the whitespace between the operator and the string literal and nowhere else.

127 ↗(On Diff #352146)

I keep coming up with 25 bits (39 bits in use), so I think this got out of sync at some point.

385 ↗(On Diff #352146)
390 ↗(On Diff #352146)
clang/lib/Basic/IdentifierTable.cpp
289 ↗(On Diff #352146)

You should fix the clang-format issue.

clang/test/Sema/reserved-identifier.cpp
84

Can you add comments about why there's no warning, as this behavior may be a bit surprising to folks. Bonus points for the comment having a link back to the standard.

rsmith added inline comments.Jun 15 2021, 1:56 PM
clang/include/clang/Basic/IdentifierTable.h
125 ↗(On Diff #352146)

This is per-declaration state; I don't think we can reasonably store it on IdentifierInfo, which is global information about an identifier. This will do the wrong thing if (for example) literal operators with the same suffix but different whitespace are declared in different scopes or if the same operator is multiply declared with different whitespace in the same scope.

Tried another not-so-intrusive approach. @rsmith?

rsmith accepted this revision.Jun 17 2021, 6:04 PM

Thanks, looks good. Just some minor comments.

clang/include/clang/Sema/Sema.h
4126

Style nit: please start variables with uppercase letters.

clang/lib/AST/Decl.cpp
1083–1084

Can you now delete this along with the added code below?

1090

Style nit: comments should start with a capital letter and end in a period.

clang/lib/Sema/SemaExprCXX.cpp
489–499

Hmm, interesting. This differs from the behavior of regular identifiers in that it will warn on both declarations and uses of reserved literal operator names. But I think that's actually a desirable difference! For example:

int _Foo(); // should warn here (if not in system header)
int k1 = _Foo(); // no need to warn here, and we shouldn't if the previous line is in a system header

int operator""_Foo();
int k2 = operator"" _Foo(); // should warn here, regardless of whether the previous line is in a system header

Given that each appearance can make a different choice in this regard, and that the problem can be fixed locally by removing the space, warning on each appearance seems like the right approach.

490

It's useful to also include a brief quotation of the relevant text and a standard version, since paragraphs get moved around and renumbered over time.

497

Can we produce a FixItHint to remove the space? (That might require the parser to pass through a little more information, such as the location for the end of the final string literal token, so we can reconstruct the space range here.)

This revision is now accepted and ready to land.Jun 17 2021, 6:04 PM

Reviews taken into account, I'm just not 100% sure of the fixit part. The out is the following:

a.cpp:4:16: warning: identifier '_Bye' is reserved because it starts with '_' followed by a capital letter [-Wreserved-identifier]
int operator"" _Bye(const char* s) {
    ~~~~~~~~~~~^~~~
    operator""_Bye
1 warning generated.

Does that look good to you?

aaron.ballman added inline comments.Jun 21 2021, 6:33 AM
clang/lib/Parse/ParseExprCXX.cpp
2639

Minor style nits

clang/lib/Sema/SemaExprCXX.cpp
487
491–493

The flow of the previous comments was basically unreadable. I think this is more readable, but at the expense of being slightly different from the standard's example comments.

495–496

Please don't use auto without the type being spelled out in the initialization.

499

Because this situation is IFNDR, do we want to upgrade this from a warning to an error (that's controlled by the warning flag)?

clang/test/Sema/reserved-identifier.cpp
79–80

Can you add test cases that use the suffix as well? Richard had an especially interesting example:

int operator""_Foo();
int k2 = operator"" _Foo(); // should warn here, regardless of whether the previous line is in a system header

Does that look good to you?

That fix-it looks correct to me.

This revision was landed with ongoing or failed builds.Jun 23 2021, 6:39 AM
This revision was automatically updated to reflect the committed changes.
serge-sans-paille marked 2 inline comments as done.