[SystemZ] Add support for new cpu architecture - arch15

This patch adds support for the next-generation arch15
CPU architecture to the SystemZ backend.

This includes:
- Basic support for the new pr

[SystemZ] Add support for new cpu architecture - arch15

This patch adds support for the next-generation arch15
CPU architecture to the SystemZ backend.

This includes:
- Basic support for the new processor and its features.
- Detection of arch15 as host processor.
- Assembler/disassembler support for new instructions.
- Exploitation of new instructions for code generation.
- New vector (signed|unsigned|bool) __int128 data types.
- New LLVM intrinsics for certain new instructions.
- Support for low-level builtins mapped to new LLVM intrinsics.
- New high-level intrinsics in vecintrin.h.
- Indicate support by defining __VEC__ == 10305.

Note: No currently available Z system supports the arch15
architecture. Once new systems become available, the
official system name will be added as supported -march name.

show more ...

[clang] Reject `_Complex _BitInt` (#119402)

The C standard doesn't require support for these types and Codegen for
these types is incorrect ATM.
See https://github.com/llvm/llvm-project/issues/119

[clang] Reject `_Complex _BitInt` (#119402)

The C standard doesn't require support for these types and Codegen for
these types is incorrect ATM.
See https://github.com/llvm/llvm-project/issues/119352

show more ...

[Sema] Remove unused includes (NFC) (#116461)

Identified with misc-include-cleaner.

[HLSL] Add HLSL 202y language mode (#108437)

This change adds a new HLSL 202y language mode. Currently HLSL 202y is
planned to add `auto` and `constexpr`.

This change updates extension diagnosti

[HLSL] Add HLSL 202y language mode (#108437)

This change adds a new HLSL 202y language mode. Currently HLSL 202y is
planned to add `auto` and `constexpr`.

This change updates extension diagnostics to state that lambadas are a
"clang HLSL" extension (since we have no planned release yet to include
them), and that `auto` is a HLSL 202y extension when used in earlier
language modes.

Note: This PR does temporarily work around some differences between HLSL
2021 and 202x in Clang by changing test cases to explicitly specify
202x. A subsequent PR will update 2021's language flags to match 202x.

show more ...

[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 ...

[C2y] Remove support for _Imaginary (#97436)

WG14 N3274 removed _Imaginary from Annex G. Clang has never fully
supported Annex G or _Imaginary, so removal is pretty trivial for us.

Note, we are

[C2y] Remove support for _Imaginary (#97436)

WG14 N3274 removed _Imaginary from Annex G. Clang has never fully
supported Annex G or _Imaginary, so removal is pretty trivial for us.

Note, we are keeping _Imaginary as a keyword so that we get better
diagnostic behavior. This is still conforming because _I makes it a
reserved identifier, so it's not available for users to use as an
identifier anyway.

show more ...

[Clang][Sema] Diagnose variable template explicit specializations with storage-class-specifiers (#93873)

According to [temp.expl.spec] p2:
> The declaration in an _explicit-specialization_ shall no

[Clang][Sema] Diagnose variable template explicit specializations with storage-class-specifiers (#93873)

According to [temp.expl.spec] p2:
> The declaration in an _explicit-specialization_ shall not be an
_export-declaration_. An explicit specialization shall not use a
_storage-class-specifier_ other than `thread_local`.

Clang partially implements this, but a number of issues exist:
1. We don't diagnose class scope explicit specializations of variable
templates with _storage-class-specifiers_, e.g.
```
struct A
{
template<typename T>
static constexpr int x = 0;

template<>
static constexpr int x<void> = 1; // ill-formed, but clang accepts
};
````
2. We incorrectly reject class scope explicit specializations of
variable templates when `static` is not used, e.g.
```
struct A
{
template<typename T>
static constexpr int x = 0;

template<>
constexpr int x<void> = 1; // error: non-static data member cannot be
constexpr; did you intend to make it static?
};
````
3. We don't diagnose dependent class scope explicit specializations of
function templates with storage class specifiers, e.g.
```
template<typename T>
struct A
{
template<typename U>
static void f();

template<>
static void f<int>(); // ill-formed, but clang accepts
};
````

This patch addresses these issues as follows:
- # 1 is fixed by issuing a diagnostic when an explicit
specialization of a variable template has storage class specifier
- # 2 is fixed by considering any non-function declaration with any
template parameter lists at class scope to be a static data member. This
also allows for better error recovery (it's more likely the user
intended to declare a variable template than a "field template").
- # 3 is fixed by checking whether a function template explicit
specialization has a storage class specifier even when the primary
template is not yet known.

One thing to note is that it would be far simpler to diagnose this when
parsing the _decl-specifier-seq_, but such an implementation would
necessitate a refactor of `ParsedTemplateInfo` which I believe to be
outside the scope of this patch.

show more ...

[Clang][Sema] Do not accept "vector _Complex" for AltiVec/ZVector (#90467)

The AltiVec (POWER) and ZVector (IBM Z) language extensions do not
support using the "vector" keyword when the element typ

[Clang][Sema] Do not accept "vector _Complex" for AltiVec/ZVector (#90467)

The AltiVec (POWER) and ZVector (IBM Z) language extensions do not
support using the "vector" keyword when the element type is a complex
type, but current code does not verify this.

Add a Sema check and diagnostic for this case.

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

show more ...

[Clang] Implement C++26 Attributes for Structured Bindings (P0609R3) (#89906)

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p0609r3.pdf

We support this feature in all language mode.

may

[Clang] Implement C++26 Attributes for Structured Bindings (P0609R3) (#89906)

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p0609r3.pdf

We support this feature in all language mode.

maybe_unused applied to a binding makes the whole declaration unused.

show more ...

[C23] Implement N3018: The constexpr specifier for object definitions (#73099)

The implementation mostly reuses C++ code paths where possible,
including narrowing check in order to provide diagnost

[C23] Implement N3018: The constexpr specifier for object definitions (#73099)

The implementation mostly reuses C++ code paths where possible,
including narrowing check in order to provide diagnostic messages in
case initializer for constexpr variable is not exactly representable in
target type.

The following won't work due to lack of support for other features:
- Diagnosing of underspecified declarations involving constexpr
- Constexpr attached to compound literals

Also due to lack of support for char8_t some of examples with utf-8
strings don't work properly.

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

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 ...

[C2X] N3007 Type inference for object definitions

Re-landing 5d78b78c8538 which was reverted.

This patches implements the auto keyword from the N3007 standard
specification.
This allows deducing th

[C2X] N3007 Type inference for object definitions

Re-landing 5d78b78c8538 which was reverted.

This patches implements the auto keyword from the N3007 standard
specification.
This allows deducing the type of the variable like in C++:
```
auto nb = 1;
auto chr = 'A';
auto str = "String";
```
The list of statements which allows the usage of auto:

* Basic variables declarations (int, float, double, char, char*...)
* Macros declaring a variable with the auto type

The list of statements which will not work with the auto keyword:

* auto arrays
* sizeof(), alignas()
* auto parameters, auto return type
* auto as a struct/typedef member
* uninitialized auto variables
* auto in an union
* auto as a enum type specifier
* auto casts
* auto in an compound literals

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

show more ...

Revert "[C2X] N3007 Type inference for object definitions"

This reverts commit 5d78b78c853830516e734cfa64bfba70479e35dc.

Reverting due to the failure found by:
https://lab.llvm.org/buildbot/#/build

Revert "[C2X] N3007 Type inference for object definitions"

This reverts commit 5d78b78c853830516e734cfa64bfba70479e35dc.

Reverting due to the failure found by:
https://lab.llvm.org/buildbot/#/builders/245/builds/14999

show more ...

[C2X] N3007 Type inference for object definitions

This patches implements the auto keyword from the N3007 standard
specification.
This allows deducing the type of the variable like in C++:
```
auto

[C2X] N3007 Type inference for object definitions

This patches implements the auto keyword from the N3007 standard
specification.
This allows deducing the type of the variable like in C++:
```
auto nb = 1;
auto chr = 'A';
auto str = "String";
```
The list of statements which allows the usage of auto:

* Basic variables declarations (int, float, double, char, char*...)
* Macros declaring a variable with the auto type

The list of statements which will not work with the auto keyword:

* auto arrays
* sizeof(), alignas()
* auto parameters, auto return type
* auto as a struct/typedef member
* uninitialized auto variables
* auto in an union
* auto as a enum type specifier
* auto casts
* auto in an compound literals

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

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 ...

Update a stale comment; NFC

This function doesn't return anything these days.

[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 ful

[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

show more ...

[Clang] NFC: Make UnqualifiedId::Kind private for consistency.

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

[clang] Use std::size instead of llvm::array_lengthof

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
help

[clang] Use std::size instead of llvm::array_lengthof

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

show more ...

[clang] adds unary type transformations as compiler built-ins

Adds

* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__rem

[clang] adds unary type transformations as compiler built-ins

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

show more ...

Revert "[clang] adds unary type transformations as compiler built-ins"

This reverts commit bc60cf2368de90918719dc7e3d7c63a72cc007ad.
Doesn't build on Windows and breaks gcc 9 build, see
https://revi

Revert "[clang] adds unary type transformations as compiler built-ins"

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.

show more ...

[clang] adds unary type transformations as compiler built-ins

Adds

* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__rem

[clang] adds unary type transformations as compiler built-ins

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

show more ...

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLEx

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat

show more ...

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no buil

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).

show more ...