[Parse] Remove ParseDiagnostic.h (#116496)

This patch removes clang/Parse/ParseDiagnostic.h because it just
forwards to clang/Basic/DiagnosticParse.h.

[HLSL] Implement intangible AST type (#97362)

HLSL has a set of intangible types which are described in in the
[draft HLSL Specification
(**[Basic.types]**)](https://microsoft.github.io/hlsl-specs

[HLSL] Implement intangible AST type (#97362)

HLSL has a set of intangible types which are described in in the
[draft HLSL Specification
(**[Basic.types]**)](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf):
There are special implementation-defined types such as handle types,
which fall into a category of standard intangible types. Intangible
types are types that have no defined object representation or value
representation, as such the size is unknown at compile time.

A class type T is an intangible class type if it contains an base
classes or members of intangible class type, standard intangible type,
or arrays of such types. Standard intangible types and intangible class
types are collectively called intangible
types([9](https://microsoft.github.io/hlsl-specs/specs/hlsl.html#Intangible)).

This PR implements one standard intangible type `__hlsl_resource_t`
and sets up the infrastructure that will make it easier to add more
in the future, such as samplers or raytracing payload handles. The
HLSL intangible types are declared in
`clang/include/clang/Basic/HLSLIntangibleTypes.def` and this file is
included with related macro definition in most places that require edits
when a new type is added.

The new types are added as keywords and not typedefs to make sure they
cannot be redeclared, and they can only be declared in builtin implicit
headers. The `__hlsl_resource_t` type represents a handle to a memory
resource and it is going to be used in builtin HLSL buffer types like this:

template <typename T>
class RWBuffer {
[[hlsl::contained_type(T)]]
[[hlsl::is_rov(false)]]
[[hlsl::resource_class(uav)]]
__hlsl_resource_t Handle;
};

Part 1/3 of llvm/llvm-project#90631.

---------

Co-authored-by: Justin Bogner <mail@justinbogner.com>

show more ...

[Clang] Fix parsing of reversible type traits in template arguments (#95969)

Constructs like `__is_pointer(Foo)` are never considered to be functions
declarations.

This matches usages in libstdc

[Clang] Fix parsing of reversible type traits in template arguments (#95969)

Constructs like `__is_pointer(Foo)` are never considered to be functions
declarations.

This matches usages in libstdc++, and we can hope
no one else redefine these reserved identifiers.

Fixes #95598

show more ...

[C++] Fix parsing of _Alignas in local declarations (#81915)

We support '_Alignas' from C11 as an extension in C++. However, we were
not correctly parsing its use in local variable declarations. Th

[C++] Fix parsing of _Alignas in local declarations (#81915)

We support '_Alignas' from C11 as an extension in C++. However, we were
not correctly parsing its use in local variable declarations. This patch
addresses that issue.

show more ...

[C23] Fix handling of alignas (#81637)

In C++, alignas is an attribute specifier, while in C23, it's an alias
of _Alignas, which is a type specifier/qualifier. This means that they
parse different

[C23] Fix handling of alignas (#81637)

In C++, alignas is an attribute specifier, while in C23, it's an alias
of _Alignas, which is a type specifier/qualifier. This means that they
parse differently in some circumstances.

Fixes https://github.com/llvm/llvm-project/issues/81472

show more ...

[Clang][Sema] Diagnose friend declarations with enum elaborated-type-specifier in all language modes (#80171)

According to [dcl.type.elab] p4:
> If an _elaborated-type-specifier_ appears with the `

[Clang][Sema] Diagnose friend declarations with enum elaborated-type-specifier in all language modes (#80171)

According to [dcl.type.elab] p4:
> If an _elaborated-type-specifier_ appears with the `friend` specifier
as an entire _member-declaration_, the _member-declaration_ shall have
one of the following forms:
> `friend` _class-key_ _nested-name-specifier_(opt) _identifier_ `;`
> `friend` _class-key_ _simple-template-id_ `;`
> `friend` _class-key_ _nested-name-specifier_ `template`(opt)
_simple-template-id_ `;`

Notably absent from this list is the `enum` form of an
_elaborated-type-specifier_ "`enum` _nested-name-specifier_(opt)
_identifier_", which appears to be intentional per the resolution of
CWG2363.

Most major implementations accept these declarations, so the diagnostic
is a pedantic warning across all C++ versions.

In addition to the trivial cases previously diagnosed in C++98, we now
diagnose cases where the _elaborated-type-specifier_ has a dependent
_nested-name-specifier_:
```
template<typename T>
struct A
{
enum class E;
};

struct B
{
template<typename T>
friend enum A<T>::E; // pedantic warning: elaborated enumeration type cannot be a friend
};

template<typename T>
struct C
{
friend enum T::E; // pedantic warning: elaborated enumeration type cannot be a friend
};
```

show more ...

[Clang][C++26] Implement Pack Indexing (P2662R3). (#72644)

Implements https://isocpp.org/files/papers/P2662R3.pdf

The feature is exposed as an extension in older language modes.
Mangling is not

[Clang][C++26] Implement Pack Indexing (P2662R3). (#72644)

Implements https://isocpp.org/files/papers/P2662R3.pdf

The feature is exposed as an extension in older language modes.
Mangling is not yet supported and that is something we will have to do before release.

show more ...

[Clang][AArch64] Change SME attributes for shared/new/preserved state. (#76971)

This patch replaces the `__arm_new_za`, `__arm_shared_za` and
`__arm_preserves_za` attributes in favour of:
* `__arm

[Clang][AArch64] Change SME attributes for shared/new/preserved state. (#76971)

This patch replaces the `__arm_new_za`, `__arm_shared_za` and
`__arm_preserves_za` attributes in favour of:
* `__arm_new("za")`
* `__arm_in("za")`
* `__arm_out("za")`
* `__arm_inout("za")`
* `__arm_preserves("za")`

As described in https://github.com/ARM-software/acle/pull/276.

One change is that `__arm_in/out/inout/preserves(S)` are all mutually
exclusive, whereas previously it was fine to write `__arm_shared_za
__arm_preserves_za`. This case is now represented with `__arm_in("za")`.

The current implementation uses the same LLVM attributes under the hood,
since `__arm_in/out/inout` are all variations of "shared ZA", so can use
the existing `aarch64_pstate_za_shared` attribute in LLVM.

#77941 will add support for the new "zt0" state as introduced
with SME2.

show more ...

[HLSL] Parameter modifier parsing and AST (#72139)

This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointer

[HLSL] Parameter modifier parsing and AST (#72139)

This change implements parsing for HLSL's parameter modifier keywords
`in`, `out` and `inout`. Because HLSL doesn't support references or
pointers, these keywords are used to allow parameters to be passed in
and out of functions.

This change only implements the parsing and AST support. In the HLSL
ASTs we represent `out` and `inout` parameters as references, and we
implement the semantics of by-value passing during IR generation.

In HLSL parameters marked `out` and `inout` are ambiguous in function
declarations, and `in`, `out` and `inout` may be ambiguous at call
sites.

This means a function may be defined as `fn(in T)` and `fn(inout T)` or
`fn(out T)`, but not `fn(inout T)` and `fn(out T)`. If a funciton `fn`
is declared with `in` and `inout` or `out` arguments, the call will be
ambiguous the same as a C++ call would be ambiguous given declarations
`fn(T)` and `fn(T&)`.

Fixes #59849

show more ...

Reapply "[clang] Support fixed point types in C++ (#67750)" (#69963)

This reverts commit d593f6cb387fe86aad47d3b763abcf0048e5b568.

Revert "[clang] Support fixed point types in C++ (#67750)" (#69963)

This reverts commit a3a7d6318027bb86e6614c022e77e0bd81aef6dc.

When compiling with MSVC2022 in C++32 mode this is giving an err

Revert "[clang] Support fixed point types in C++ (#67750)" (#69963)

This reverts commit a3a7d6318027bb86e6614c022e77e0bd81aef6dc.

When compiling with MSVC2022 in C++32 mode this is giving an error.
Compiling this simple test case:
t1.cpp:
with -std=c++23 will give the following error:

In file included from C:\Users\zahiraam\t1.cpp:1:
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3329:16:
error:
compile with '-ffixed-point' to enable fixed point types
3329 | _Vbase _Accum = 0;
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3329:23:
error:
expected unqualified-id
3329 | _Vbase _Accum = 0;
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3334:13:
error:
compile with '-ffixed-point' to enable fixed point types
3334 | _Accum |= _Tmp ? _Mask : _Vbase{0};
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3334:20:
error:
expected unqualified-id
3334 | _Accum |= _Tmp ? _Mask : _Vbase{0};
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3336:53:
error:
expected '(' for function-style cast or type construction
3336 | this->_Emplace_back_unchecked(_Accum);
| ~~~~~~^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3337:17:
error:
compile with '-ffixed-point' to enable fixed point types
3337 | _Accum = 0;
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3337:24:
error:
expected unqualified-id
3337 | _Accum = 0;
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3343:49:
error:
expected '(' for function-style cast or type construction
3343 | this->_Emplace_back_unchecked(_Accum);
| ~~~~~~^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3352:16:
error:
compile with '-ffixed-point' to enable fixed point types
3352 | _Vbase _Accum = 0;
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3352:26:
error:
expected unqualified-id
3352 | _Vbase _Accum = 0;
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3357:13:
error:
compile with '-ffixed-point' to enable fixed point types
3357 | _Accum |= _Tmp ? _Mask : _Vbase{0};
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3357:20:
error:
expected unqualified-id
3357 | _Accum |= _Tmp ? _Mask : _Vbase{0};
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3359:46:
error:
expected '(' for function-style cast or type construction
3359 | this->_Myvec.push_back(_Accum);
| ~~~~~~^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3360:17:
error:
compile with '-ffixed-point' to enable fixed point types
3360 | _Accum = 0;
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3360:24:
error:
expected unqualified-id
3360 | _Accum = 0;
| ^
c:\Program files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.35.32215\include\vector:3366:42:
error:
expected '(' for function-style cast or type construction
3366 | this->_Myvec.push_back(_Accum);
| ~~~~~~^
16 errors generated.

See also comment here:
https://github.com/llvm/llvm-project/pull/67750#issuecomment-1775264907

show more ...

[C++] Implement "Deducing this" (P0847R7)

This patch implements P0847R7 (partially),
CWG2561 and CWG2653.

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm

[C++] Implement "Deducing this" (P0847R7)

This patch implements P0847R7 (partially),
CWG2561 and CWG2653.

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm.org/D140828

show more ...

[clang] Support fixed point types in C++ (#67750)

This initially just adds support for mangling.

[clang-repl] Disambiguate declarations with private typedefs

Member functions and static variable definitions may use typedefs that
are private in the global context, but fine in the class context.

[clang-repl] Disambiguate declarations with private typedefs

Member functions and static variable definitions may use typedefs that
are private in the global context, but fine in the class context.

Differential Revision: https://reviews.llvm.org/D157838

show more ...

[clang-repl] Disambiguate global namespace identifiers

A double colon starts an identifier name in the global namespace and
must be tentatively parsed as such.

Differential Revision: https://review

[clang-repl] Disambiguate global namespace identifiers

A double colon starts an identifier name in the global namespace and
must be tentatively parsed as such.

Differential Revision: https://reviews.llvm.org/D157480

show more ...

[Clang] Fix crash in isCXXDeclarationSpecifier when attempting to annotate template name

When attempting to decide if in C++17 a type template for class template
argument deduction and the code is i

[Clang] Fix crash in isCXXDeclarationSpecifier when attempting to annotate template name

When attempting to decide if in C++17 a type template for class template
argument deduction and the code is ill-formed the condition to break is
checking the current token is an identifier when it should be checking
if the next token is not ::.

This fixes: https://github.com/llvm/llvm-project/issues/57495
https://github.com/llvm/llvm-project/issues/63052

Differential Revision: https://reviews.llvm.org/D134334

show more ...

[C] Support _Generic expressions with a type operand

_Generic accepts an expression operand whose type is matched against a
list of associations. The expression operand is unevaluated, but the
type

[C] Support _Generic expressions with a type operand

_Generic accepts an expression operand whose type is matched against a
list of associations. The expression operand is unevaluated, but the
type matched is the type after lvalue conversion. This conversion loses
type information, which makes it more difficult to match against
qualified or incomplete types.

This extension allows _Generic to accept a type operand instead of an
expression operand. The type operand form does not undergo any
conversions and is matched directly against the association list.

This extension is also supported in C++ as we already supported
_Generic selection expressions there.

The RFC for this extension can be found at:
https://discourse.llvm.org/t/rfc-generic-selection-expression-with-a-type-operand/70388

Differential Revision: https://reviews.llvm.org/D149904

show more ...

[clang] Add Parse and Sema support for RegularKeyword attributes

This patch adds the Parse and Sema support for RegularKeyword attributes,
following on from a previous patch that added Attr.td suppo

[clang] Add Parse and Sema support for RegularKeyword attributes

This patch adds the Parse and Sema support for RegularKeyword attributes,
following on from a previous patch that added Attr.td support.

The patch is quite large. However, nothing outside the tests is
specific to the first RegularKeyword attribute (__arm_streaming).
The patch should therefore be a one-off, up-front cost. Other
attributes just need an entry in Attr.td and the usual Sema support.

The approach taken in the patch is that the keywords can be used with
any language version. If standard attributes were added in language
version Y, the keyword rules for version X<Y are the same as they were
for version Y (to the extent possible). Any extensions beyond Y are
handled in the same way for both keywords and attributes. This ensures
that existing C++11 successors like C++17 are not treated differently
from versions that have yet to be defined.

Some notes on the implementation:

* The patch emits errors rather than warnings for diagnostics that
relate to keywords.

* Where possible, the patch drops “attribute” from diagnostics
relating to keywords.

* One exception to the previous point is that warnings about C++
extensions do still mention attributes. The use there seemed OK
since the diagnostics are noting a change in the production rules.

* If a diagnostic string needs to be different for keywords and
attributes, the patch standardizes on passing the attribute/
name/token followed by 0 for attributes and 1 for keywords.

* Although the patch updates warn_attribute_wrong_decl_type_str,
warn_attribute_wrong_decl_type, and warn_attribute_wrong_decl_type,
only the error forms of these strings are used for keywords.

* I couldn't trigger the warnings in checkUnusedDeclAttributes,
even for existing attributes. An assert on the warnings caused
no failures in the testsuite. I think in practice all standard
attributes would be diagnosed before this.

* The patch drops a call to standardAttributesAllowed in
ParseFunctionDeclarator. This is because MaybeParseCXX11Attributes
checks the same thing itself, where appropriate.

* The new tests are based on c2x-attributes.c and
cxx0x-attributes.cpp. The C++ test also incorporates a version of
cxx11-base-spec-attributes.cpp. The FIXMEs are carried across from
the originals.

Differential Revision: https://reviews.llvm.org/D148702

show more ...

[Clang] Fix parsing of `(auto(x))`.

Allow auto(x) to appear in a parenthesis
expression.

The pattern (auto( can appear as part of a declarator,
so the parser is modified to avoid the ambiguity,
in

[Clang] Fix parsing of `(auto(x))`.

Allow auto(x) to appear in a parenthesis
expression.

The pattern (auto( can appear as part of a declarator,
so the parser is modified to avoid the ambiguity,
in a way consistent with the proposed resolution to CWG1223.

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm.org/D149276

show more ...

Revert "[Clang] Fix parsing of `(auto(x))`."

This reverts commit ef47318ec3615e83c328b07341046dfb9d869414.

This patch breaks valid code https://reviews.llvm.org/D149276#4345620

[Clang] Fix parsing of `(auto(x))`.

Allow auto(x) to appear in a parenthesis
expression.

The pattern (auto( can appear as part of a declarator,
so the parser is modified to avoid the ambiguity,
in

[Clang] Fix parsing of `(auto(x))`.

Allow auto(x) to appear in a parenthesis
expression.

The pattern (auto( can appear as part of a declarator,
so the parser is modified to avoid the ambiguity,
in a way consistent with the proposed resolution to CWG1223.

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm.org/D149276

show more ...

[clang-repl] Consider the scope spec in template lookups for deduction guides.

isDeductionGuideName looks up the underlying template and if the template name
is qualified we miss that qualification

[clang-repl] Consider the scope spec in template lookups for deduction guides.

isDeductionGuideName looks up the underlying template and if the template name
is qualified we miss that qualification resulting in an error. This issue
resurfaced in clang-repl where we call isDeductionGuideName more often to
distinguish between if we had a statement or declaration.

This patch passes the CXXScopeSpec information down to LookupTemplateName to
make the lookup more precise.

Differential revision: https://reviews.llvm.org/D147319

show more ...

[clang-repl] Correctly disambiguate dtor declarations from statements.

Differential revision: https://reviews.llvm.org/D148425

[clang][WebAssembly] Initial support for reference type funcref in clang

This is the funcref counterpart to 890146b. We introduce a new attribute
that marks a function pointer as a funcref. It also

[clang][WebAssembly] Initial support for reference type funcref in clang

This is the funcref counterpart to 890146b. We introduce a new attribute
that marks a function pointer as a funcref. It also implements builtin
__builtin_wasm_ref_null_func(), that returns a null funcref value.

Differential Revision: https://reviews.llvm.org/D128440

show more ...

[clang-repl] Support statements on global scope in incremental mode.

This patch teaches clang to parse statements on the global scope to allow:
```
./bin/clang-repl
clang-repl> int i = 12;
clang-rep

[clang-repl] Support statements on global scope in incremental mode.

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

show more ...