llvm-project.git/llvm/lib/Option/ArgList.cpp, branch users/nico/python-2 Unnamed repository; edit this file 'description' to name the repository. [llvm] Remove unused includes (NFC) (#142733) 2025-06-04T19:30:52+00:00 Kazu Hirata kazu@google.com 2025-06-04T19:30:52+00:00 228f66807d0be1d7873e075fc81baf41001950b5 These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures. 
These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
 [LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133) 2024-09-19T15:16:38+00:00 Jay Foad jay.foad@amd.com 2024-09-19T15:16:38+00:00 e03f427196ec67a8a5cfbdd658f9eabe9bce83ce It is almost always simpler to use {} instead of std::nullopt to initialize an empty ArrayRef. This patch changes all occurrences I could find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor could be deprecated or removed. 
It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.
 [llvm] Use StringRef::{starts,ends}_with (NFC) (#74956) 2023-12-12T05:01:36+00:00 Kazu Hirata kazu@google.com 2023-12-12T05:01:36+00:00 586ecdf205aa8b3d162da6f955170a6736656615 This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with. 
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
 ArgList: Simplify 3-opt overload of AddAllArgs. NFC 2023-10-12T08:15:28+00:00 Fangrui Song i@maskray.me 2023-10-12T08:15:28+00:00 af74f06322410e867294ea3587e5884342564e5c 






[Driver] Rename AddAllArgs (initialization list overload) to addAllArgs
2023-10-11T04:31:18+00:00

Fangrui Song
i@maskray.me

2023-10-11T04:31:18+00:00

4eecfda50a4e7a05f448a59885d2572d0ea2f4a1

Most ArgList member functions use the modern functionName style while some like
AddAllArgs use the legacy FunctionName style. These uses are mostly linker
options which have been modified recently to fix duplicate -e issues, so just
update these call sites.





Most ArgList member functions use the modern functionName style while some like
AddAllArgs use the legacy FunctionName style. These uses are mostly linker
options which have been modified recently to fix duplicate -e issues, so just
update these call sites.







[Driver] Adjust -fsanitize=function & -mexecute-only interop after D158614
2023-08-31T03:30:13+00:00

Fangrui Song
i@maskray.me

2023-08-31T03:30:13+00:00

c7dce0283b5b502dacd47eb1488342a31f4ed35a

clangDriver depends on clangBasic, so clangBasic should not depend on
clangDriver, even just its header. Also remove clangBasic's dependency
on LLVMOption.

The issue can be seen through the bazel commit
d26dd681f9726ed7d43d7c0bdd8ee3cb2db69a2b which is reverted now.

Add hasFlagNoClaim and use it as we don't want to suppress
-Wunused-command-line-argument for -mexecute-only just because
-fsanitize= is specified.





clangDriver depends on clangBasic, so clangBasic should not depend on
clangDriver, even just its header. Also remove clangBasic's dependency
on LLVMOption.

The issue can be seen through the bazel commit
d26dd681f9726ed7d43d7c0bdd8ee3cb2db69a2b which is reverted now.

Add hasFlagNoClaim and use it as we don't want to suppress
-Wunused-command-line-argument for -mexecute-only just because
-fsanitize= is specified.







[ADT] Don't including None.h (NFC)
2022-12-07T04:14:51+00:00

Kazu Hirata
kazu@google.com

2022-12-07T04:14:51+00:00

405fc404bf84fcc13e10bfac754d398199f69b7d

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





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







[llvm] Use std::nullopt instead of None (NFC)
2022-12-03T05:11:44+00:00

Kazu Hirata
kazu@google.com

2022-12-03T05:11:44+00:00

aadaaface2ec96ee30d92bf46faa41dd9e68b64d

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





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







[llvm] Qualify auto in range-based for loops (NFC)
2022-08-29T06:29:00+00:00

Kazu Hirata
kazu@google.com

2022-08-29T06:29:00+00:00

0e9d37ff95b5c574a8fde65bb176691e1a17d70d












[Driver] Simplify hasFlag pattern with addOptInFlag/addOptOutFlag helpers
2022-04-11T19:29:25+00:00

Fangrui Song
i@maskray.me

2022-04-11T19:29:25+00:00

aefa4b60cebaeada796a161bab036bf145790b00

Reviewed By: dexonsmith

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





Reviewed By: dexonsmith

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