maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Lexer/keywords_test.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

55 lines
1.6 KiB
C
Raw Normal View History

Add a test to distinguish between reserved tokens and normal identifiers. The -fms-extensions option affects a number of subtle front-end C/C++ behaviors, and it would be useful to be able to distinguish MS keywords from regular identifiers in the ms-extensions mode even if the triple does not define a Windows target. It should make life easier if anyone needs to port their Windows codes to elsewhere. Differential Revision: http://reviews.llvm.org/D3034 llvm-svn: 206069
2014-04-12 04:55:19 +08:00
// RUN: %clang_cc1 -std=c99 -E %s -o - | FileCheck --check-prefix=CHECK-NONE %s
// RUN: %clang_cc1 -std=gnu89 -E %s -o - \
// RUN: | FileCheck --check-prefix=CHECK-GNU-KEYWORDS %s
// RUN: %clang_cc1 -std=c99 -fgnu-keywords -E %s -o - \
// RUN: | FileCheck --check-prefix=CHECK-GNU-KEYWORDS %s
// RUN: %clang_cc1 -std=gnu89 -fno-gnu-keywords -E %s -o - \
// RUN: | FileCheck --check-prefix=CHECK-NONE %s
[MSVC] Recognize `static_assert` keyword in C and C++98 Summary: The main effect is that clang now accepts the following conforming C11 code with MSVC headers: #include <assert.h> static_assert(1, "true"); This is a non-conforming extension (the keyword is outside the implementer's namespace), so it is placed under -fms-compatibility instead of -fms-extensions like most MSVC-specific keyword extensions. Normally, in C11, the compiler is supposed to provide the _Static_assert keyword, and assert.h should define static_assert to _Static_assert. However, that is not what MSVC does, and MSVC doesn't even provide _Static_assert. This also has the less important side effect of enabling static_assert in C++98 mode with -fms-compatibility. It's exceptionally difficult to use modern MSVC headers without C++14 even, so this is relatively unimportant. Fixes PR26672 Patch by Andrey Bokhanko! Reviewers: rsmith, thakis Subscribers: cfe-commits, STL_MSFT Differential Revision: https://reviews.llvm.org/D17444 llvm-svn: 354162
2019-02-16 03:59:45 +08:00
// RUN: %clang_cc1 -std=c99 -fms-extensions -fms-compatibility -E %s -o - \
Add a test to distinguish between reserved tokens and normal identifiers. The -fms-extensions option affects a number of subtle front-end C/C++ behaviors, and it would be useful to be able to distinguish MS keywords from regular identifiers in the ms-extensions mode even if the triple does not define a Windows target. It should make life easier if anyone needs to port their Windows codes to elsewhere. Differential Revision: http://reviews.llvm.org/D3034 llvm-svn: 206069
2014-04-12 04:55:19 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS %s
Add -f[no-]declspec to control recognition of __declspec as a keyword In versions of clang prior to r238238, __declspec was recognized as a keyword in all modes. It was then changed to only be enabled when Microsoft or Borland extensions were enabled (and for CUDA, as a temporary measure). There is a desire to support __declspec in Playstation code, and possibly other environments. This commit adds a command-line switch to allow explicit enabling/disabling of the recognition of __declspec as a keyword. Recognition is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and disabled in all other environments. Patch by Warren Ristow! llvm-svn: 249279
2015-10-05 01:51:05 +08:00
// RUN: %clang_cc1 -std=c99 -fdeclspec -E %s -o - \
// RUN: | FileCheck --check-prefix=CHECK-DECLSPEC-KEYWORD %s
// RUN: %clang_cc1 -std=c99 -fms-extensions -fno-declspec -E %s -o - \
// RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC %s
Add a test to distinguish between reserved tokens and normal identifiers. The -fms-extensions option affects a number of subtle front-end C/C++ behaviors, and it would be useful to be able to distinguish MS keywords from regular identifiers in the ms-extensions mode even if the triple does not define a Windows target. It should make life easier if anyone needs to port their Windows codes to elsewhere. Differential Revision: http://reviews.llvm.org/D3034 llvm-svn: 206069
2014-04-12 04:55:19 +08:00
void f() {
// CHECK-NONE: int asm
// CHECK-GNU-KEYWORDS: asm ("ret" : :)
#if __is_identifier(asm)
int asm;
#else
asm ("ret" : :);
#endif
}
// CHECK-NONE: no_ms_wchar
// CHECK-MS-KEYWORDS: has_ms_wchar
Add -f[no-]declspec to control recognition of __declspec as a keyword In versions of clang prior to r238238, __declspec was recognized as a keyword in all modes. It was then changed to only be enabled when Microsoft or Borland extensions were enabled (and for CUDA, as a temporary measure). There is a desire to support __declspec in Playstation code, and possibly other environments. This commit adds a command-line switch to allow explicit enabling/disabling of the recognition of __declspec as a keyword. Recognition is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and disabled in all other environments. Patch by Warren Ristow! llvm-svn: 249279
2015-10-05 01:51:05 +08:00
// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: has_ms_wchar
Add a test to distinguish between reserved tokens and normal identifiers. The -fms-extensions option affects a number of subtle front-end C/C++ behaviors, and it would be useful to be able to distinguish MS keywords from regular identifiers in the ms-extensions mode even if the triple does not define a Windows target. It should make life easier if anyone needs to port their Windows codes to elsewhere. Differential Revision: http://reviews.llvm.org/D3034 llvm-svn: 206069
2014-04-12 04:55:19 +08:00
#if __is_identifier(__wchar_t)
void no_ms_wchar();
#else
void has_ms_wchar();
#endif
Add -f[no-]declspec to control recognition of __declspec as a keyword In versions of clang prior to r238238, __declspec was recognized as a keyword in all modes. It was then changed to only be enabled when Microsoft or Borland extensions were enabled (and for CUDA, as a temporary measure). There is a desire to support __declspec in Playstation code, and possibly other environments. This commit adds a command-line switch to allow explicit enabling/disabling of the recognition of __declspec as a keyword. Recognition is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and disabled in all other environments. Patch by Warren Ristow! llvm-svn: 249279
2015-10-05 01:51:05 +08:00
// CHECK-NONE: no_declspec
// CHECK-MS-KEYWORDS: has_declspec
// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: no_declspec
// CHECK-DECLSPEC-KEYWORD: has_declspec
#if __is_identifier(__declspec)
void no_declspec();
#else
void has_declspec();
#endif
[MSVC] Recognize `static_assert` keyword in C and C++98 Summary: The main effect is that clang now accepts the following conforming C11 code with MSVC headers: #include <assert.h> static_assert(1, "true"); This is a non-conforming extension (the keyword is outside the implementer's namespace), so it is placed under -fms-compatibility instead of -fms-extensions like most MSVC-specific keyword extensions. Normally, in C11, the compiler is supposed to provide the _Static_assert keyword, and assert.h should define static_assert to _Static_assert. However, that is not what MSVC does, and MSVC doesn't even provide _Static_assert. This also has the less important side effect of enabling static_assert in C++98 mode with -fms-compatibility. It's exceptionally difficult to use modern MSVC headers without C++14 even, so this is relatively unimportant. Fixes PR26672 Patch by Andrey Bokhanko! Reviewers: rsmith, thakis Subscribers: cfe-commits, STL_MSFT Differential Revision: https://reviews.llvm.org/D17444 llvm-svn: 354162
2019-02-16 03:59:45 +08:00
// CHECK-NONE: no_static_assert
// CHECK-GNU-KEYWORDS: no_static_assert
// CHECK-MS-KEYWORDS: has_static_assert
// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: no_static_assert
#if __is_identifier(static_assert)
void no_static_assert();
#else
void has_static_assert();
#endif