hanchenye-llvm-project/clang/test/Preprocessor/extension-warning.c

// RUN: %clang_cc1 -fsyntax-only -verify -pedantic %s

// The preprocessor shouldn't warn about extensions within macro bodies that
// aren't expanded.
#define TY typeof
#define TY1 typeof(1)

// But we should warn here
TY1 x; // expected-warning {{extension}}
TY(1) x; // FIXME: And we should warn here

// Note: this warning intentionally doesn't trigger on keywords like
// __attribute; the standard allows implementation-defined extensions
// prefixed with "__".
// Current list of keywords this can trigger on:
// inline, restrict, asm, typeof, _asm

void whatever() {}
Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'. - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446 2009-12-16 04:14:24 +08:00			`// RUN: %clang_cc1 -fsyntax-only -verify -pedantic %s`
- Implement __block. - Replace FIXME in Preprocessor::HandleIdentifier() with a check that avoids diagnosing extension tokens that originate from macro definitions. llvm-svn: 55639 2008-09-03 02:50:17 +08:00
			`// The preprocessor shouldn't warn about extensions within macro bodies that`
			`// aren't expanded.`
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281 2009-04-28 11:13:54 +08:00			`#define TY typeof`
			`#define TY1 typeof(1)`
- Implement __block. - Replace FIXME in Preprocessor::HandleIdentifier() with a check that avoids diagnosing extension tokens that originate from macro definitions. llvm-svn: 55639 2008-09-03 02:50:17 +08:00
Simplify the scheme used for keywords, and change the classification scheme to be more useful. The new scheme introduces a set of categories that should be more readable, and also reflects what we want to consider as an extension more accurately. Specifically, it makes the "what is a keyword" determination accurately reflect whether the keyword is a GNU or Microsoft extension. I also introduced separate flags for keyword aliases; this is useful because the classification of the aliases is mostly unrelated to the classification of the original keyword. This patch treats anything that's in the implementation namespace (prefixed with "__", or "_X" where "X" is any upper-case letter) as a keyword without marking it as an extension. This is consistent with the standards in that an implementation is allowed to define arbitrary extensions in the implementation namespace without violating the standard. This gets rid of all the nasty "extension used" warnings for stuff like __attribute__ in -pedantic mode. We still warn for extensions outside of the the implementation namespace, like typeof. If someone wants to implement -Wextensions or something like that, we could add additional information to the keyword table. This also removes processing for the unused "Boolean" language option; such an extension isn't supported on any other C implementation, so I don't see any point to adding it. The changes to test/CodeGen/inline.c are required because previously, we weren't actually disabling the "inline" keyword in -std=c89 mode. I'll remove Boolean and NoExtensions from LangOptions in a follow-up commit. llvm-svn: 70281 2009-04-28 11:13:54 +08:00			`// But we should warn here`
			`TY1 x; // expected-warning {{extension}}`
			`TY(1) x; // FIXME: And we should warn here`

			`// Note: this warning intentionally doesn't trigger on keywords like`
			`// __attribute; the standard allows implementation-defined extensions`
			`// prefixed with "__".`
			`// Current list of keywords this can trigger on:`
			`// inline, restrict, asm, typeof, _asm`
- Implement __block. - Replace FIXME in Preprocessor::HandleIdentifier() with a check that avoids diagnosing extension tokens that originate from macro definitions. llvm-svn: 55639 2008-09-03 02:50:17 +08:00
			`void whatever() {}`