[PATCH] D93095: Introduce -Wreserved-identifier

[serge via Phabricator via cfe-commits]

serge-sans-paille marked an inline comment as done.
serge-sans-paille added inline comments.


================
Comment at: clang/test/Sema/reserved-identifier.c:9
+int _foo() { return 0; }        // expected-warning {{'_foo' is a reserved identifier}}
+
+// This one is explicitly skipped by -Wreserved-identifier
----------------
Quuxplusone wrote:
> aaron.ballman wrote:
> > Can you add a test that we do not warn on an extern declaration? e.g.,
> > ```
> > extern char *_strdup(const char *);
> > ```
> > This is sometimes used (esp in older C code bases) to avoid having to include an entire header to scrape one declaration out of it, and there are popular libraries (like the MSVC CRT) that have APIs starting with a single underscore and lowercase letter.
> > 
> > The idea here is: if it's an extern declaration, the identifier is "owned" by some other declaration and this is not likely something the user has control over.
> Should that logic also apply to a forward declaration like `struct _foo;`? Should it apply to `struct _foo { int i; };`? These are also things the user might not have control over. (And they're equally things that the user //could// pull out into a separate .h file surrounded by disabled-warning pragmas, if they really wanted to.)
I'd say 100% yeah to the forward declaration, but I'm unsure about the actual definition, because there's no way to distinguish it from a user definition.


================
Comment at: clang/test/Sema/reserved-identifier.c:24
+  _Other,     // expected-warning {{'_Other' is a reserved identifier}}
+  _other      // no-warning
+};
----------------
aaron.ballman wrote:
> I'm on the fence about whether this should have no warning or not. Enumeration constants in C (and sometimes in C++, depending on the enumeration) are in the enclosing scope. e.g.,
> ```
> enum foo {
>   _bar
> };
> 
> int i = _bar;
> ```
> So if a user has an enumeration constant named `_bar`, the implementation is not free to add `int _bar(void);` as it will cause compile errors. WDYT?
We could state it that way: would the code still compile if there's a `int _bar` symbol defined in a system header. here the answer is no, so reserved.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93095/new/

https://reviews.llvm.org/D93095