Fix bugs found when actually trying to use formatv() automatic index
assignment in IntrinsicEmitter.cpp:
- Assign automatic index only for `ReplacementType::Format`.
- Make the check for all replacement indices being either automatic orexplicit more accurate.
The existing check fails for formatv("{}{0}{}", 0, 1) (added as a unit test). Explicitly track if we
have seen any explicit and any automatic index instead.
Make index in replacement field optional. It will be automatically
assigned in incremental order by formatv.
Make mixed use of automatic and explicit indices an error that will fail
validation.
Adopt uses of formatv() within FormatVariadic to use automatic index.
- Rename `Align` field in ReplacementItem/FmtAlign to `Width` to
accurately reflect its use.
- Change both `Width` and `Index` in ReplacementItem to 32-bit int
instead of size_t (as 64-bits seems excessive in this context).
- Eliminate the use of `Empty` ReplacementType, and use the
existing std::optional<> instead to indicate that.
- Eliminate some boilerplate type code in formatv().
- Eliminate the loop in `splitLiteralAndReplacement`. The existing
code will never loop back.
- Directly use constructor instead of std::make_pair.
Change formatv() to validate that the number of arguments passed matches
number of replacement fields in the format string, and that the replacement
indices do not contain holes.
To support cases where this cannot be guaranteed, introduce a formatv()
overload that allows disabling validation with a bool flag as its first argument.
- When an unterminated open { is detected in the format string, instead
of asserting and ignoring the error, replace that string with another to
indicate the error, and remove the assert as well.
- This will make the error evident in both assert and release builds and
make observing the error more convenient (as several uses of this
function are in TableGen and it is often built in release mode even in
debug builds)
Some support code, e.g. llvm/Support/Endian.h, uses
llvm::support::detail, but the format-related code uses llvm::detail. On
VS2019, when a C++ file includes both headers, a `detail::` from
`namespace llvm { ... }` becomes ambiguous.
44253a9c breaks TensorFlow and
[JAX](https://github.com/google/jax/actions/runs/8507773013/job/23300219405)
build because of this.
Since llvm::X::detail seems like a cleaner solution and is used in other
places as well (e.g. llvm::yaml::detail), we should probably migrate all
llvm::detail usages to llvm::X::detail.
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
- Eliminate `From` which is 0 most of the times.
- Replace 'find_first_of('{') != 0' with 'front() != '{'
- Simplify the loop body given the it executes only when front() == '}'
Differential Revision: https://reviews.llvm.org/D84178
- Move Adapters array to the stack, we know the size precisely
- Parse format string on demand into a SmallVector. In theory this could
lead to parsing it multiple times, but I couldn't find a single instance
of that in LLVM.
- Make more of the implementation details private.
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This introduces a new type-safe general purpose formatting
library. It provides compile-time type safety, does not require
a format specifier (since the type is deduced), and provides
mechanisms for extending the format capability to user defined
types, and overriding the formatting behavior for existing types.
This patch additionally adds documentation for the API to the
LLVM programmer's manual.
Mailing List Thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/105836.html
Differential Revision: https://reviews.llvm.org/D25587
llvm-svn: 286682
