Commit Graph

5 Commits

Author SHA1 Message Date
Aaron Ballman 60727d8569 [C2x] implement typeof and typeof_unqual
This implements WG14 N2927 and WG14 N2930, which together define the
feature for typeof and typeof_unqual, which get the type of their
argument as either fully qualified or fully unqualified. The argument
to either operator is either a type name or an expression. If given a
type name, the type information is pulled directly from the given name.
If given an expression, the type information is pulled from the
expression. Recursive use of these operators is allowed and has the
expected behavior (the innermost operator is resolved to a type, and
that's used to resolve the next layer of typeof specifier, until a
fully resolved type is determined.

Note, we already supported typeof in GNU mode as a non-conforming
extension and we are *not* exposing typeof_unqual as a non-conforming
extension in that mode, nor are we exposing typeof or typeof_unqual as
a nonconforming extension in other language modes. The GNU variant of
typeof supports a form where the parentheses are elided from the
operator when given an expression (e.g., typeof 0 i = 12;). When in C2x
mode, we do not support this extension.

Differential Revision: https://reviews.llvm.org/D134286
2022-09-28 13:27:52 -04:00
Muhammad Usman Shahid 41667a8b9b Diagnosing the Future Keywords
The patch diagnoses an identifier as a future keyword if it exists in a
future language mode, such as:

int restrict;

in C modes earlier than C99. We now give a warning to the user that
such an identifier is a future keyword. Handles keywords from C as well
as C++.

Differential Revision: https://reviews.llvm.org/D131683
2022-08-26 09:20:05 -04:00
Reid Kleckner c1648f2bfd [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-15 19:59:45 +00:00
Saleem Abdulrasool d170c4b57a 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-04 17:51:05 +00:00
Yunzhong Gao ef309f4326 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-11 20:55:19 +00:00