https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.
This adds extension warnings and documentation for the functionality
Clang explicitly supports.
Fixes#57065
Reverts the revert of 39da55e8f548a11f7dadefa73ea73d809a5f1729
Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Differential Revision: https://reviews.llvm.org/D133574
DeclResult tracks two states: valid/invalid and usable/unusable.
Passing a null pointer to the constructor creates a valid but unusable
result and we wanted an invalid result instead. This changes some
functions to return a DeclResult rather than a Decl * to make it harder
to get this incorrect in callers.
Discovered when working on https://reviews.llvm.org/D141280.
Co-authored-by: Haojian Wu <hokein@google.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Differential Revision: https://reviews.llvm.org/D141580
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.
This adds extension warnings and documentation for the functionality
Clang explicitly supports.
Fixes#57065
Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This patch teaches clang to parse statements on the global scope to allow:
```
./bin/clang-repl
clang-repl> int i = 12;
clang-repl> ++i;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> printf("%d\n", i);
13
clang-repl> %quit
```
Generally, disambiguating between statements and declarations is a non-trivial
task for a C++ parser. The challenge is to allow both standard C++ to be
translated as if this patch does not exist and in the cases where the user typed
a statement to be executed as if it were in a function body.
Clang's Parser does pretty well in disambiguating between declarations and
expressions. We have added DisambiguatingWithExpression flag which allows us to
preserve the existing and optimized behavior where needed and implement the
extra rules for disambiguating. Only few cases require additional attention:
* Constructors/destructors -- Parser::isConstructorDeclarator was used in to
disambiguate between ctor-looking declarations and statements on the global
scope(eg. `Ns::f()`).
* The template keyword -- the template keyword can appear in both declarations
and statements. This patch considers the template keyword to be a declaration
starter which breaks a few cases in incremental mode which will be tackled
later.
* The inline (and similar) keyword -- looking at the first token in many cases
allows us to classify what is a declaration.
* Other language keywords and specifiers -- ObjC/ObjC++/OpenCL/OpenMP rely on
pragmas or special tokens which will be handled in subsequent patches.
The patch conceptually models a "top-level" statement into a TopLevelStmtDecl.
The TopLevelStmtDecl is lowered into a void function with no arguments.
We attach this function to the global initializer list to execute the statement
blocks in the correct order.
Differential revision: https://reviews.llvm.org/D127284
As reported in https://github.com/llvm/llvm-project/issues/49192,
we did a pretty poor job diagnosing cases where someone forgot 'auto', a
nd is probably in the middle of a variable declaration. This patch
makes us properly diagnose in cases where the next token is a reference,
or CVR qualifier.
Added keyword, LangAS and TypeAttrbute for groupshared.
Tanslate it to LangAS with asHLSLLangAS.
Make sure it translated into address space 3 for DirectX target.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D135060
The parser assumes that the lexer never emits coloncolon token for C code, but this assumption no longer holds in C2x attribute namespaces. As a result, stray coloncolon tokens out of attributes cause assertion failures and hangs in release build, which this patch tries to handle.
Crash input minimal example: `T n::v`
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D133248
Allow register binding attribute on variables.
Report warning when register binding attribute applies to local variable or static variable.
It will be ignored in this case.
Type check for register binding is tracked with https://github.com/llvm/llvm-project/issues/57886.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D134617
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
This patch implements P0634r3 that removes the need for 'typename' in certain contexts.
For example,
```
template <typename T>
using foo = T::type; // ok
```
This is also allowed in previous language versions as an extension, because I think it's pretty useful. :)
Reviewed By: #clang-language-wg, erichkeane
Differential Revision: https://reviews.llvm.org/D53847
This is first part for support cbuffer/tbuffer.
The format for cbuffer/tbuffer is
BufferType [Name] [: register(b#)] { VariableDeclaration [: packoffset(c#.xyzw)]; ... };
More details at https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-constants
New keyword 'cbuffer' and 'tbuffer' are added.
New AST node HLSLBufferDecl is added.
Build AST for simple cbuffer/tbuffer without attribute support.
The special thing is variables declared inside cbuffer is exposed into global scope.
So isTransparentContext should return true for HLSLBuffer.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129883
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.
Change call sites to use `std::size` instead. Leave the few call sites that
use a locally defined `array_lengthof` that are meant to test previous bugs
with NTTPs in clang analyzer and SemaTemplate.
Differential Revision: https://reviews.llvm.org/D133520
In Parser::ParseUsingDeclaration(...) when we call ParseEnumSpecifier(...) it is
not calling SetTypeSpecError() on DS when it detects an error. That means that
DS is left set to TST_unspecified. When we then pass DS into
Sema::ActOnUsingEnumDeclaration(...) we hit an llvm_unreachable(...) since it
expects it to be one of three states TST_error, TST_enum or TST_typename.
This fixes https://github.com/llvm/llvm-project/issues/57347
Differential Revision: https://reviews.llvm.org/D132695
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
This reverts commit bc60cf2368de90918719dc7e3d7c63a72cc007ad.
Doesn't build on Windows and breaks gcc 9 build, see
https://reviews.llvm.org/D116203#3722094 and
https://reviews.llvm.org/D116203#3722128
Also revert two follow-ups. One fixed a warning added in
bc60cf2368de90918719dc7e3d7c63a72cc007ad, the other
makes use of the feature added in bc60cf2368de90918719dc7e3d7c63a72cc007ad
in libc++:
Revert "[libcxx][NFC] utilises compiler builtins for unary transform type-traits"
This reverts commit 06a1d917ef1f507aaa2f6891bb654696c866ea3a.
Revert "[Sema] Fix a warning"
This reverts commit c85abbe879ef3257de4db862ce249b060cc3d2a4.
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
C99 6.7.4p2 clarifies that a function specifier can only be used in the
declaration of a function. _Noreturn is a function specifier, so it is
a constraint violation to write it on a structure or union field, but
we missed that case.
Fixes#56800
report an error when encountering 'while' token parsing declarator
```
clang/test/Parser/while-loop-outside-function.c:3:1: error: while loop outside of a function
while // expected-error {{while loop outside of a function}}
^
clang/test/Parser/while-loop-outside-function.c:7:1: error: while loop outside of a function
while // expected-error {{while loop outside of a function}}
^
```
Fixes: https://github.com/llvm/llvm-project/issues/34462
Differential Revision: https://reviews.llvm.org/D129573
"Ascii" StringLiteral instances are actually narrow strings
that are UTF-8 encoded and do not have an encoding prefix.
(UTF8 StringLiteral are also UTF-8 encoded strings, but with
the u8 prefix.
To avoid possible confusion both with actuall ASCII strings,
and with future works extending the set of literal encodings
supported by clang, this rename StringLiteral::isAscii() to
isOrdinary(), matching C++ standard terminology.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D128762
Before D126061, Clang would warn about this code
```
struct X {
[[deprecated]] struct Y {};
};
```
with the warning
attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration
D126061 inadvertently caused this warning to no longer be emitted. This patch
restores the previous behavior.
The reason for the bug is that after D126061, C++11 attributes applied to a
member declaration are no longer placed in `DS.getAttributes()` but are instead
tracked in a separate list (`DeclAttrs`). In the case of a free-standing
decl-specifier-seq, we would simply ignore the contents of this list. Instead,
we now pass the list on to `Sema::ParsedFreeStandingDeclSpec()` so that it can
issue the appropriate warning.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D128499
For backwards compatiblity, we emit only a warning instead of an error if the
attribute is one of the existing type attributes that we have historically
allowed to "slide" to the `DeclSpec` just as if it had been specified in GNU
syntax. (We will call these "legacy type attributes" below.)
The high-level changes that achieve this are:
- We introduce a new field `Declarator::DeclarationAttrs` (with appropriate
accessors) to store C++11 attributes occurring in the attribute-specifier-seq
at the beginning of a simple-declaration (and other similar declarations).
Previously, these attributes were placed on the `DeclSpec`, which made it
impossible to reconstruct later on whether the attributes had in fact been
placed on the decl-specifier-seq or ahead of the declaration.
- In the parser, we propgate declaration attributes and decl-specifier-seq
attributes separately until we can place them in
`Declarator::DeclarationAttrs` or `DeclSpec::Attrs`, respectively.
- In `ProcessDeclAttributes()`, in addition to processing declarator attributes,
we now also process the attributes from `Declarator::DeclarationAttrs` (except
if they are legacy type attributes).
- In `ConvertDeclSpecToType()`, in addition to processing `DeclSpec` attributes,
we also process any legacy type attributes that occur in
`Declarator::DeclarationAttrs` (and emit a warning).
- We make `ProcessDeclAttribute` emit an error if it sees any non-declaration
attributes in C++11 syntax, except in the following cases:
- If it is being called for attributes on a `DeclSpec` or `DeclaratorChunk`
- If the attribute is a legacy type attribute (in which case we only emit
a warning)
The standard justifies treating attributes at the beginning of a
simple-declaration and attributes after a declarator-id the same. Here are some
relevant parts of the standard:
- The attribute-specifier-seq at the beginning of a simple-declaration
"appertains to each of the entities declared by the declarators of the
init-declarator-list" (https://eel.is/c++draft/dcl.dcl#dcl.pre-3)
- "In the declaration for an entity, attributes appertaining to that entity can
appear at the start of the declaration and after the declarator-id for that
declaration." (https://eel.is/c++draft/dcl.dcl#dcl.pre-note-2)
- "The optional attribute-specifier-seq following a declarator-id appertains to
the entity that is declared."
(https://eel.is/c++draft/dcl.dcl#dcl.meaning.general-1)
The standard contains similar wording to that for a simple-declaration in other
similar types of declarations, for example:
- "The optional attribute-specifier-seq in a parameter-declaration appertains to
the parameter." (https://eel.is/c++draft/dcl.fct#3)
- "The optional attribute-specifier-seq in an exception-declaration appertains
to the parameter of the catch clause" (https://eel.is/c++draft/except.pre#1)
The new behavior is tested both on the newly added type attribute
`annotate_type`, for which we emit errors, and for the legacy type attribute
`address_space` (chosen somewhat randomly from the various legacy type
attributes), for which we emit warnings.
Depends On D111548
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D126061
Currently, Clang accepts this code in C mode (where the tag is required
to be used) but rejects it in C++ mode thinking that the association is
defining a new type.
void foo(void) {
struct S { int a; };
_Generic(something, struct S : 1);
}
Clang thinks this in C++ because it sees struct S : when parsing the
class specifier and decides that must be a type definition (because the
colon signifies the presence of a base class type). This patch adds a
new declarator context to represent a _Generic association so that we
can distinguish these situations properly.
Fixes#55562
Differential Revision: https://reviews.llvm.org/D126969
With sufficiently tortured code, it's possible to cause a stack
overflow when parsing declarators. Thus, we now check for resource
exhaustion when recursively parsing declarators so that we can at least
warn the user we're about to crash before we actually crash.
Fixes#51642
Differential Revision: https://reviews.llvm.org/D124915
CUDA/HIP programs use __noinline__ like a keyword e.g.
__noinline__ void foo() {} since __noinline__ is defined
as a macro __attribute__((noinline)) in CUDA/HIP runtime
header files.
However, gcc and clang supports __attribute__((__noinline__))
the same as __attribute__((noinline)). Some C++ libraries
use __attribute__((__noinline__)) in their header files.
When CUDA/HIP programs include such header files,
clang will emit error about invalid attributes.
This patch fixes this issue by supporting __noinline__ as
a keyword, so that CUDA/HIP runtime could remove
the macro definition.
Reviewed by: Aaron Ballman, Artem Belevich
Differential Revision: https://reviews.llvm.org/D124866
We had a think-o that would allow a user to declare a scoped
enumeration in C language modes "as a C++11 extension". This is a
think-o because there's no way for the user to spell the name of the
enumerators; C does not have '::' for a fully-qualified name. See
commit d0d87b597259a2b74ae5c2825a081c7e336cb1d0 for details on why this
is unintentional for C.
Fixes#42372
C89 allowed a type specifier to be elided with the resulting type being
int, aka implicit int behavior. This feature was subsequently removed
in C99 without a deprecation period, so implementations continued to
support the feature. Now, as with implicit function declarations, is a
good time to reevaluate the need for this support.
This patch allows -Wimplicit-int to issue warnings in C89 mode (off by
default), defaults the warning to an error in C99 through C17, and
disables support for the feature entirely in C2x. It also removes a
warning about missing declaration specifiers that really was just an
implicit int warning in disguise and other minor related cleanups.
WG14 has elected to remove support for K&R C functions in C2x. The
feature was introduced into C89 already deprecated, so after this long
of a deprecation period, the committee has made an empty parameter list
mean the same thing in C as it means in C++: the function accepts no
arguments exactly as if the function were written with (void) as the
parameter list.
This patch implements WG14 N2841 No function declarators without
prototypes (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm)
and WG14 N2432 Remove support for function definitions with identifier
lists (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf).
It also adds The -fno-knr-functions command line option to opt into
this behavior in other language modes.
Differential Revision: https://reviews.llvm.org/D123955
HLSL has a language feature called Semantics which get attached to
declarations like attributes and are used in a variety of ways.
One example of semantic use is here with the `SV_GroupIndex` semantic
which, when applied to an input for a compute shader is pre-populated
by the driver with a flattened thread index.
Differential Revision: https://reviews.llvm.org/D122699
# Conflicts:
# clang/include/clang/Basic/Attr.td
# clang/include/clang/Basic/AttrDocs.td
As statement expression makes no sense in the default argument,
this patch tries to disable it in the all cases.
Please note that the statement expression is a GNU extension, which
means that Clang should be consistent with GCC. However, there's no
response from GCC devs since we have raised the issue for several weeks.
In this case, I think we can disallow statement expressions as a default
parameter in general for now, and relax the restriction if GCC folks
decide to retain the feature for functions but not lambdas in the
future.
Related discussion: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104765
Fixes https://github.com/llvm/llvm-project/issues/53488
Differential Revision: https://reviews.llvm.org/D119609
Move the SourceRange from the old ParsedAttributesWithRange into
ParsedAttributesView, so we have source range information available
everywhere we use attributes.
This also removes ParsedAttributesWithRange (replaced by simply using
ParsedAttributes) and ParsedAttributesVieWithRange (replaced by using
ParsedAttributesView).
Differential Revision: https://reviews.llvm.org/D121201
