[clang][NFC] Fix FieldDecl::isUnnamedBitfield() capitalization (#89048)

We always capitalize bitfield as "BitField".

[RISCV] Remove Type::isRVVType() and replace with isRVVSizelessBuiltinType(). NFC

These both do the same thing, but some profiling on a
Releast+Asserts build suggests isRVVSizelessBuiltinType() is t

[RISCV] Remove Type::isRVVType() and replace with isRVVSizelessBuiltinType(). NFC

These both do the same thing, but some profiling on a
Releast+Asserts build suggests isRVVSizelessBuiltinType() is the
more efficient version so lets keep that one.

show more ...

[clang][NFC] Remove trailing whitespaces and enforce it in lib, include and docs

A lot of editors remove trailing whitespaces. This patch removes any trailing whitespaces and makes sure that no new

[clang][NFC] Remove trailing whitespaces and enforce it in lib, include and docs

A lot of editors remove trailing whitespaces. This patch removes any trailing whitespaces and makes sure that no new ones are added.

Reviewed By: erichkeane, paulkirth, #libc, philnik

Spies: wangpc, aheejin, MaskRay, pcwang-thead, cfe-commits, libcxx-commits, dschuff, nemanjai, arichardson, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, s.egerton, sameer.abuasal, apazos, luismarques, martong, frasercrmck, steakhal, luke

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

show more ...

No longer diagnose (functionally) empty structures under -Wuninitialized

An empty structure in C has no way to be initialized, so triggering a
-Wuninitialized warning for a variable of empty structu

No longer diagnose (functionally) empty structures under -Wuninitialized

An empty structure in C has no way to be initialized, so triggering a
-Wuninitialized warning for a variable of empty structure type is not
actionable for users. This silences the false positive warning, which
matches the behavior of GCC as well.

We no longer diagnose if the structure has no members, or has only
zero-sized members (unnamed bit-fields, zero-sized bit-fields, empty
structure types).

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

show more ...

[clang] fix -Wuninitialized for asm goto outputs on indirect edges.

Now that we support outputs from asm goto along indirect edges, we can
remove/revert some code that was added to help warn about t

[clang] fix -Wuninitialized for asm goto outputs on indirect edges.

Now that we support outputs from asm goto along indirect edges, we can
remove/revert some code that was added to help warn about the previous
limitation that outputs were not supported along indirect edges.

Reverts some code added in:
commit 72aa619a7fe0 ("Warn of uninitialized variables on asm goto's indirect branch")
commit 3a604fdbcd5f ("[Clang][CFG] check children statements of asm goto")
But keeps+updates the tests.

Link: https://github.com/llvm/llvm-project/issues/53562

Reviewed By: void

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

show more ...

[clang] Remove remaining uses of llvm::Optional (NFC)

This patch removes several "using" declarations and #include
"llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to

[clang] Remove remaining uses of llvm::Optional (NFC)

This patch removes several "using" declarations and #include
"llvm/ADT/Optional.h".

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

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

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

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
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 ...

llvm::Optional::value => operator*/operator->

std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The

llvm::Optional::value => operator*/operator->

std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.

This makes `ninja clang` work in the absence of llvm::Optional::value.

show more ...

[clang] Don't including None.h (NFC)

These source files no longer use None, so they do not need to include
None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https:

[clang] Don't including None.h (NFC)

These source files no longer use None, so they do not need to include
None.h.

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

[Analysis] 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 o

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

[RISCV][clang] Support RISC-V vectors in UninitializedValues.

RISC-V vectors are basically vectors, but we use builtin types to
restrict the possible types. Treat them the same as vectors and scalar

[RISCV][clang] Support RISC-V vectors in UninitializedValues.

RISC-V vectors are basically vectors, but we use builtin types to
restrict the possible types. Treat them the same as vectors and scalars
for this analysis.

Reviewed By: reames

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

show more ...

[clang] Use value instead of getValue (NFC)

[clang] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[Clang][CFG] check children statements of asm goto

When performing CFG based analyses, don't forget to check the child
statements of an asm goto, such as the expressions used for
inputs+outputs.

Fi

[Clang][CFG] check children statements of asm goto

When performing CFG based analyses, don't forget to check the child
statements of an asm goto, such as the expressions used for
inputs+outputs.

Fixes: https://github.com/llvm/llvm-project/issues/51024
Fixes: https://github.com/ClangBuiltLinux/linux/issues/1439

Reviewed By: void, jyknight, jyu2, efriedma

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

show more ...

[Analysis] Ignore casts and unary ops for uninitialized values

A series of unary operators and casts may obscure the variable we're
trying to analyze. Ignore them for the uninitialized value analysi

[Analysis] Ignore casts and unary ops for uninitialized values

A series of unary operators and casts may obscure the variable we're
trying to analyze. Ignore them for the uninitialized value analysis.
Other checks determine if the unary operators result in a valid l-value.

Link: https://github.com/ClangBuiltLinux/linux/issues/1521

Reviewed By: nickdesaulniers

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

show more ...

[SemaCXX] Fix false positive of -Wuninitialized-const-reference in empty function body.

Summary:
Some libraries use empty function to ignore unused variable warnings, which gets a new warning from `

[SemaCXX] Fix false positive of -Wuninitialized-const-reference in empty function body.

Summary:
Some libraries use empty function to ignore unused variable warnings, which gets a new warning from `-Wuninitialized-const-reference`, discussed here https://reviews.llvm.org/D79895#2107604.
This patch should fix that.

Reviewers: hans, nick, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: aaron.ballman, riccibruno, cfe-commits

Tags: #clang

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

show more ...

[Sema] Use isAlwaysUninit for -Wuninitialized-const-reference after D79895

[Clang] Add a new warning to warn when passing uninitialized variables as const reference parameters to a function

Summary:
Add a new warning -Wuninitialized-const-reference as a subgroup of -Wunini

[Clang] Add a new warning to warn when passing uninitialized variables as const reference parameters to a function

Summary:
Add a new warning -Wuninitialized-const-reference as a subgroup of -Wuninitialized to address a bug filed here: https://bugs.llvm.org/show_bug.cgi?id=45624

This warning is controlled by -Wuninitialized and can be disabled by -Wno-uninitialized-const-reference.
The warning is diagnosed when passing uninitialized variables as const reference parameters to a function.

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

show more ...

Warn of uninitialized variables on asm goto's indirect branch

Summary:
Outputs from an asm goto block cannot be used on the indirect branch.
It's not supported and may result in invalid code generat

Warn of uninitialized variables on asm goto's indirect branch

Summary:
Outputs from an asm goto block cannot be used on the indirect branch.
It's not supported and may result in invalid code generation.

Reviewers: jyknight, nickdesaulniers, hfinkel

Reviewed By: nickdesaulniers

Subscribers: martong, cfe-commits, rnk, craig.topper, hiraditya, rsmith

Tags: #clang

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

show more ...

[Analysis] Fix -Wrange-loop-analysis after D69876

Support output constraints on "asm goto"

Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not

Support output constraints on "asm goto"

Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.

Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.

In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.

Reviewers: jyknight, nickdesaulniers, hfinkel

Reviewed By: jyknight, nickdesaulniers

Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk

Tags: #clang, #llvm

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

show more ...

[DataFlow] Factor two worklist implementations out

Right now every dataflow algorithm uses its own worklist implementation.
This is a first step to reduce this duplication. Some upcoming
algorithms

[DataFlow] Factor two worklist implementations out

Right now every dataflow algorithm uses its own worklist implementation.
This is a first step to reduce this duplication. Some upcoming
algorithms such as the lifetime analysis is going to use the factored
out implementations.

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

show more ...