[Clang] Fix variant crashes from GH58028, GH57370

Fixes a null dereference in some diagnostic issuing code.

Closes https://github.com/llvm/llvm-project/issues/57370
Closes https://github.com/llvm/l

[Clang] Fix variant crashes from GH58028, GH57370

Fixes a null dereference in some diagnostic issuing code.

Closes https://github.com/llvm/llvm-project/issues/57370
Closes https://github.com/llvm/llvm-project/issues/58028

Reviewed By: shafik

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

(cherry picked from commit 9415aad6a40fec74296008a25f34164a95c857f4)

show more ...

[Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]

"Ascii" StringLiteral instances are actually narrow strings
that are UTF-8 encoded and do not have an encoding prefix.
(UTF8 StringLiter

[Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]

"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

show more ...

Fix an unused-variable warning in release build, NFC.

[HLSL] Support HLSL vector initializers

In HLSL vectors are ext_vectors in all respects except that they
support a constructor style syntax for initializing vectors. This
change adds a translation o

[HLSL] Support HLSL vector initializers

In HLSL vectors are ext_vectors in all respects except that they
support a constructor style syntax for initializing vectors. This
change adds a translation of vector constructor arguments into
initializer lists.

This supports two oddities of HLSL syntax:
(1) HLSL vectors support constructor syntax
(2) HLSL vectors are expanded to constituate components in constructors

Reviewed By: aaron.ballman

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

show more ...

[Sema] Reject list-initialization of enumeration types from a
brace-init-list containing a single element of a different scoped
enumeration type

It is rejected because it doesn't satisfy the conditi

[Sema] Reject list-initialization of enumeration types from a
brace-init-list containing a single element of a different scoped
enumeration type

It is rejected because it doesn't satisfy the condition that the element
has to be implicitly convertible to the underlying type of the
enumeration.

http://eel.is/c++draft/dcl.init.list#3.8

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

show more ...

[randstruct] Move initializer check to be more effective

If a randomized structure has an initializer with a dedicated
initializer in it, the field initialzed by that dedicated initializer
may end u

[randstruct] Move initializer check to be more effective

If a randomized structure has an initializer with a dedicated
initializer in it, the field initialzed by that dedicated initializer
may end up at the end of the RecordDecl. This however may skip the
random layout initization check.

struct t {
int a, b, c, d, e;
} x = { .a = 2, 4, 5, 6 };

Let's say that "a" is lands as the last field after randomization. The
call to CheckDesignatedInitializer sets the iterator to the end of the
initializer list. During the next iteration of the initializer list
check, it detects that and fails to issue the error about initializing
a randomized struct with non-designated initializer. Instead, it issues
an error about "excess elements in struct initializer", which is
confusing under these circumstances.

Reviewed By: aaron.ballman

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

show more ...

[randstruct] Randomize all elements of a record

A record may have more than just FieldDecls in it. If so, then we're
likely to drop them if we only randomize the FieldDecls.

We need to be careful a

[randstruct] Randomize all elements of a record

A record may have more than just FieldDecls in it. If so, then we're
likely to drop them if we only randomize the FieldDecls.

We need to be careful about anonymous structs/unions. Their fields are
made available in the RecordDecl as IndirectFieldDecls, which are listed
after the anonymous struct/union. The ordering doesn't appear to be
super important, however we place them unrandomized at the end of the
RecordDecl just in case. There's also the possiblity of
StaticAssertDecls. We also want those at the end.

All other non-FieldDecls we place at the top, just in case we get
something like:

struct foo {
enum e { BORK };
enum e a;
};

Link: https://github.com/KSPP/linux/issues/185

Reviewed By: aaron.ballman

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

show more ...

Treat `std::move`, `forward`, etc. as builtins.

This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`,

Treat `std::move`, `forward`, etc. as builtins.

This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

This is a re-commit of
fc3090109643af8d2da9822d0f99c84742b9c877,
a571f82a50416b767fd3cce0fb5027bb5dfec58c,
64c045e25b8471bbb572bd29159c294a82a86a2, and
de6ddaeef3aaa8a9ae3663c12cdb57d9afc0f906,
and reverts aa643f455a5362de7189eac630050d2c8aefe8f2.
This change also includes a workaround for users using libc++ 3.1 and
earlier (!!), as apparently happens on AIX, where std::move sometimes
returns by value.

Reviewed By: aaron.ballman

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

Revert "Fixup D123950 to address revert of D123345"

This reverts commit aa643f455a5362de7189eac630050d2c8aefe8f2.

show more ...

Revert "Treat `std::move`, `forward`, etc. as builtins."

This reverts commit b27430f9f46b88bcd54d992debc8d72e131e1bd0 as the
parent https://reviews.llvm.org/D123345 breaks the AIX CI:

https

Revert "Treat `std::move`, `forward`, etc. as builtins."

This reverts commit b27430f9f46b88bcd54d992debc8d72e131e1bd0 as the
parent https://reviews.llvm.org/D123345 breaks the AIX CI:

https://lab.llvm.org/buildbot/#/builders/214/builds/819

show more ...

[clang] Add a raw_ostream operator<< overload for QualType

Under the hood this prints the same as `QualType::getAsString()` but cuts out the middle-man when that string is sent to another raw_ostrea

[clang] Add a raw_ostream operator<< overload for QualType

Under the hood this prints the same as `QualType::getAsString()` but cuts out the middle-man when that string is sent to another raw_ostream.

Also cleaned up all the call sites where this occurs.

Reviewed By: aaron.ballman

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

show more ...

Treat `std::move`, `forward`, etc. as builtins.

This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`,

Treat `std::move`, `forward`, etc. as builtins.

This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

This is a re-commit of
fc3090109643af8d2da9822d0f99c84742b9c877,
a571f82a50416b767fd3cce0fb5027bb5dfec58c, and
64c045e25b8471bbb572bd29159c294a82a86a25
which were reverted in
e75d8b70370435b0ad10388afba0df45fcf9bfcc
due to a crasher bug where CodeGen would emit a builtin glvalue as an
rvalue if it constant-folds.

Reviewed By: aaron.ballman

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

show more ...

[randstruct] Enforce using a designated init for a randomized struct

A randomized structure needs to use a designated or default initializer.
Using a non-designated initializer will result in values

[randstruct] Enforce using a designated init for a randomized struct

A randomized structure needs to use a designated or default initializer.
Using a non-designated initializer will result in values being assigned
to the wrong fields.

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

show more ...

Revert "[randstruct] Enforce using a designated init for a randomized struct"

This reverts commit aed923b1246ac38335b222b89594516fcf0d6385.

It causes some buildbot test failures.

Revert "Treat `std::move`, `forward`, and `move_if_noexcept` as builtins."
Revert "Extend support for std::move etc to also cover std::as_const and"
Revert "Update test to handle opaque pointers flag

Revert "Treat `std::move`, `forward`, and `move_if_noexcept` as builtins."
Revert "Extend support for std::move etc to also cover std::as_const and"
Revert "Update test to handle opaque pointers flag flip."

It crashes on libcxx tests https://lab.llvm.org/buildbot/#/builders/85/builds/8174

This reverts commit fc3090109643af8d2da9822d0f99c84742b9c877.
This reverts commit a571f82a50416b767fd3cce0fb5027bb5dfec58c.
This reverts commit 64c045e25b8471bbb572bd29159c294a82a86a25.

show more ...

Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addres

Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

Reviewed By: aaron.ballman

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

show more ...

[randstruct] Enforce using a designated init for a randomized struct

A randomized structure needs to use a designated or default initializer.
Using a non-designated initializer will result in values

[randstruct] Enforce using a designated init for a randomized struct

A randomized structure needs to use a designated or default initializer.
Using a non-designated initializer will result in values being assigned
to the wrong fields.

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

show more ...

Allow flexible array initialization in C++.

Flexible array initialization is a C/C++ extension implemented in many
compilers to allow initializing the flexible array tail of a struct type
that conta

Allow flexible array initialization in C++.

Flexible array initialization is a C/C++ extension implemented in many
compilers to allow initializing the flexible array tail of a struct type
that contains a flexible array. In clang, this is currently restricted
to C. But this construct is used in the Microsoft SDK headers, so I'd
like to extend it to C++.

For now, this doesn't handle dynamic initialization; probably not hard
to implement, but it's extra code, and I don't think it's necessary for
the expected uses. And we explicitly fail out of constant evaluation.

I've added some additional code to assert that initializers have the
correct size, with or without flexible array init. This might catch
issues unrelated to flexible array init.

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

show more ...

[Format, Sema] Use range-based for loops with llvm::reverse (NFC)

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses th

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <[email protected]>

Reviewed By: rsmith, #libc, ldionne

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

show more ...

Revert "[clang] retain type sugar in auto / template argument deduction"

This reverts commit 4d8fff477e024698facd89741cc6cf996708d598.

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses th

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <[email protected]>

Reviewed By: rsmith

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

show more ...

Revert "[clang] retain type sugar in auto / template argument deduction"

This reverts commit 9b6036deedf28e10d797fc4ca734d57680d18053.
Breaks two libc++ tests.

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses th

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <[email protected]>

Reviewed By: rsmith

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

show more ...

[Sema] Use llvm::is_contained (NFC)

[clang] do not emit note for bad conversion when destination type qualifiers are not compatibly include source type qualifiers

llvm.org/PR52014

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

[clang] do not emit note for bad conversion when destination type qualifiers are not compatibly include source type qualifiers

llvm.org/PR52014

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

show more ...