History log of /llvm-project/clang/lib/Sema/SemaInit.cpp (Results 151 – 175 of 1122)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 40c52159 03-Oct-2022 Alan Zhao <ayzhao@google.com>

[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

This patch implements P0960R3, which allows initialization of aggregates
via parentheses.

As an

[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

This patch implements P0960R3, which allows initialization of aggregates
via parentheses.

As an example:

```
struct S { int i, j; };
S s1(1, 1);

int arr1[2](1, 2);
```

This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:

```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;

int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```

This patch was originally authored by @0x59616e and completed by
@ayzhao.

Fixes #54040, Fixes #54041

Co-authored-by: Sheng <ox59616e@gmail.com>

Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744

Reviewed By: ilya-biryukov

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

show more ...


# 8595f2e5 03-Dec-2022 Kazu Hirata <kazu@google.com>

[Sema] Use std::nullopt instead of None (NFC)

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 ma

[Sema] Use std::nullopt instead of None (NFC)

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

show more ...


# 94738a5a 08-Nov-2022 Rageking8 <tomleetyt@gmail.com>

Fix duplicate word typos; NFC

This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs)

Fix duplicate word typos; NFC

This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.

show more ...


# 94186347 07-Nov-2022 Kazu Hirata <kazu@google.com>

[clang] Use llvm::reverse (NFC)


# d0d27723 21-Oct-2022 Corentin Jabot <corentinjabot@gmail.com>

[Clang] Implement P2513

Implement P2513

This change allows initializing an array of unsigned char,
or char from u8 string literals.
This was done both to support legacy code and for compatibility
w

[Clang] Implement P2513

Implement P2513

This change allows initializing an array of unsigned char,
or char from u8 string literals.
This was done both to support legacy code and for compatibility
with C where char8_t will be typedef to unsigned char.

This is backported to C++20 as per WG21 guidance.

Reviewed By: aaron.ballman

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

show more ...


# 464926ef 18-Oct-2022 Xiang Li <python3kgae@outlook.com>

[HLSL] Disable integer promotion to avoid int16_t being promoted to int for HLSL.

short will be promoted to int in UsualUnaryConversions.
Disable it for HLSL to keep int16_t as 16bit.

Reviewed By:

[HLSL] Disable integer promotion to avoid int16_t being promoted to int for HLSL.

short will be promoted to int in UsualUnaryConversions.
Disable it for HLSL to keep int16_t as 16bit.

Reviewed By: aaron.ballman, rjmccall

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

show more ...


# 9415aad6 29-Sep-2022 Roy Jacobson <roi.jacobson1@gmail.com>

[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

show more ...


# 894c0e94 30-Sep-2022 Roy Jacobson <roi.jacobson1@gmail.com>

Revert "[Clang] Fix variant crashes from GH58028, GH57370"

This reverts commit 9706bb3165f5e508d5e2247ad8a3f45077df546d, some CI workers complain about the test.


# 9706bb31 29-Sep-2022 Roy Jacobson <roi.jacobson1@gmail.com>

[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

show more ...


# 6523814c 29-Sep-2022 Roy Jacobson <roi.jacobson1@gmail.com>

[Clang] P1169R4: static operator()

Implements 'P1169R4: static operator()' from C++2b.

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

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


# b7a7aeee 04-Sep-2022 Kazu Hirata <kazu@google.com>

[clang] Qualify auto in range-based for loops (NFC)


# 3d2ab237 11-Aug-2022 Timm Bäder <tbaeder@redhat.com>

[clang] Improve diagnostics for uninitialized constexpr variables

Instead of complaining about default initialization, tell users that
constexpr variables need to be initialized by a constant expres

[clang] Improve diagnostics for uninitialized constexpr variables

Instead of complaining about default initialization, tell users that
constexpr variables need to be initialized by a constant expression.

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

show more ...


# 3f18f7c0 08-Aug-2022 Fangrui Song <i@maskray.me>

[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

Reviewed By: aaron.ballman

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


# 127bf443 30-Mar-2022 Corentin Jabot <corentinjabot@gmail.com>

[Clang][C++20] Support capturing structured bindings in lambdas

This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++

[Clang][C++20] Support capturing structured bindings in lambdas

This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.

In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.

We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.

In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.

Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.

at the request of @shafik, i can confirm the correct behavior of lldb wit this change.

Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720

Reviewed By: aaron.ballman

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

show more ...


# a2742196 03-Aug-2022 Corentin Jabot <corentinjabot@gmail.com>

Revert "[Clang][C++20] Support capturing structured bindings in lambdas"

This reverts commit 44f2baa3804a62ca793f0ff3e43aa71cea91a795.

Breaks self builds and seems to have conformance issues.


# 44f2baa3 30-Mar-2022 Corentin Jabot <corentinjabot@gmail.com>

[Clang][C++20] Support capturing structured bindings in lambdas

This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++

[Clang][C++20] Support capturing structured bindings in lambdas

This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.

In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.

We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.

In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.

Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.

at the request of @shafik, i can confirm the correct behavior of lldb wit this change.

Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720

Reviewed By: aaron.ballman

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

show more ...


# a9a60f20 28-Jun-2022 Corentin Jabot <corentinjabot@gmail.com>

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


# 7b7166f1 21-Jun-2022 Haojian Wu <hokein.wu@gmail.com>

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


# 9f499d9d 14-Jun-2022 Chris Bieneman <chris.bieneman@me.com>

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


# 66e08995 20-May-2022 Akira Hatanaka <ahatanaka@apple.com>

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


# f2639cf3 03-May-2022 Bill Wendling <isanbard@gmail.com>

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


# 463790bf 28-Apr-2022 Bill Wendling <isanbard@gmail.com>

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


# 72315d02 21-Apr-2022 Richard Smith <richard@metafoo.co.uk>

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


# 98d911e0 20-Apr-2022 David Tenty <daltenty@ibm.com>

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


# cfb81690 20-Apr-2022 Nathan James <n.james93@hotmail.co.uk>

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


12345678910>>...45