Warn when a declaration uses an identifier that doesn't obey the reserved
identifier rule from C and/or C++.
Do not perform the check at preprocessor level because:
- it will be quite costly
- we don't have accurate linkage info at that point
Differential D93095
Introduce -Wreserved-identifier serge-sans-paille on Dec 11 2020, 2:03 AM. Authored by
Details Warn when a declaration uses an identifier that doesn't obey the reserved Do not perform the check at preprocessor level because:
Diff Detail
Unit Tests Event TimelineThere are a very large number of changes, so older changes are hidden. Show Older Changes
Comment Actions Take review into account, some extra tests suggested by @aaron.ballman and the according modification in Decl.cpp Comment Actions Adding Richard for another interpreter of the standards.
Comment Actions Instead of pretending to be smart, just consider that if the considered decl is at the top level, then it's a top-level decl, otherwise it's not. There may be some interpretation wrt. the standard, but this seems both simple and conservative to me. It gies a few false negative, but it's a warning here, so that should be fine.
Comment Actions As suggested by @aaron.ballman base the detection of top-level-ness on Sema::LookupName to avoid re-implementing the wheel.
Comment Actions Back to the previous version, as suggested by @rsmith . I made a few updates to NamedDecl::isReserved which get me close to the expected result, without too much overhead.
Comment Actions There is a GNU extension where the linker provides symbols for section / start end, and using these with this patch would produce a warning. [[gnu::section("foo")]] void bar() {} extern "C" void __start_foo(); extern "C" void __stop_foo();
Comment Actions Adress final(?) comments from @rsmith and @aaron.ballman :
Comment Actions Address all the needed changes pointed out by @aaron.ballman *except* the most critical one on the call to warnOnReservedIdentifier being spread at several place in Sema. I'll try to find a better approach for that particular point.
Comment Actions Another round of review :-) I addressed both the scattering of warnOnReservedIdentifier and the code split between Decl.cpp and IdentifierInfo.cpp.
Comment Actions Warn on friend functions. I failed to support friend classes, but they are only declared and not defined, so that should be fine, right?
Comment Actions They can still conflict, so I think we should warn. For example: // user code struct A { friend struct _b; }; // system header enum _b {}; // error
Comment Actions Aside from the formatting nit and the question about the diagnostic, I think this LGTM!
|
Because this is not a scoped enum, should these enumerators get an RIR_ prefix added to them?