[NFC][YAML] Add `IO::error()` (#123475)

For #123280

[YAML] Fix incorrect dash output in nested sequences (#116488)

Nested sequences could be defined but the YAML output was incorrect.
`Output::newLineCheck()` was not able to emit multiple dashes `-

[YAML] Fix incorrect dash output in nested sequences (#116488)

Nested sequences could be defined but the YAML output was incorrect.
`Output::newLineCheck()` was not able to emit multiple dashes `- ` and
YAML parser sometimes didn't accept its output as the result.

This fixes for emitting corresponding dashes for consecutive
`inSeqFirstElement`, but suppresses emission to the top
`inSeqFirstElement`.

This also fixes for emitting flow elements onto nested sequences.

show more ...

[Support] Remove unused includes (NFC) (#116752)

Identified with misc-include-cleaner.

[Support] Use StringRef::operator== instead of StringRef::equals (NFC) (#91042)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator== outnumbers Str

[Support] Use StringRef::operator== instead of StringRef::equals (NFC) (#91042)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator== outnumbers StringRef::equals by a factor of 25
under llvm/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".

show more ...

[Support][YamlTraits] Add quoting for keys in textual YAML representation (#88763)

The support library contains helpers to parse and emit YAML documents.

In the textual YAML representation, some

[Support][YamlTraits] Add quoting for keys in textual YAML representation (#88763)

The support library contains helpers to parse and emit YAML documents.

In the textual YAML representation, some strings need to be quoted, e.g.
when containing unprintable characters.

We already have such quoting implemented for YAML values.

This patch applies the same quoting to YAML *keys*.

One affected case is output of control registers in AMDGPU Msgpack
metadata, which are printed in a format like this:

```
0x2cca (SPI_SHADER_PGM_RSRC1_ES): 42
```

With this patch, the key is quoted:

```
'0x2cca (SPI_SHADER_PGM_RSRC1_ES)': 42
```

Most test changes come from this pattern.

show more ...

[YAMLTraits] Fix std::optional input on empty documents (#68947)

When the input document is non-empty, `mapOptional` works as expected,
setting `std::optional` to `std::nullopt` when the field is n

[YAMLTraits] Fix std::optional input on empty documents (#68947)

When the input document is non-empty, `mapOptional` works as expected,
setting `std::optional` to `std::nullopt` when the field is not present.
When the input document is empty, we hit a special case inside of
`Input::preflightKey` that results in `UseDefault = false`, which
results in the `std::optional` erroneously being set to a non-nullopt
value. `preflightKey` is changed to set `UseDefault = true` in this case
to make the behavior consistent between empty and non-empty documents.

show more ...

[YAML][NFC] Use BumpPtrAllocator instead of unique_ptrs

Avoid both memory leaks and expensive dynamic allocations by using
SpecificBumpPtrAllocator for HNode types. It's expected they're not dealloc

[YAML][NFC] Use BumpPtrAllocator instead of unique_ptrs

Avoid both memory leaks and expensive dynamic allocations by using
SpecificBumpPtrAllocator for HNode types. It's expected they're not deallocated
until the `Input` class is destroyed, so deallocating all at once works well in
this case.

Reduces YAML profile pre-processing time in BOLT from
> 11.2067 ( 3.2%) 1.6487 ( 7.3%) 12.8554 ( 3.5%) 12.8635 ( 5.6%) pre-process profile data
to
> 10.6613 ( 3.1%) 1.6489 ( 6.7%) 12.3102 ( 3.3%) 12.3134 ( 5.3%) pre-process profile data

Reviewed By: dblaikie

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

show more ...

[YAML][NFC] Replace if-else with switch in createHNodes

BOLT YAML profile reading time gets marginally faster (14.1572->13.9207 s) for
a large YAML profile (121MB/31K functions). Not claiming stat s

[YAML][NFC] Replace if-else with switch in createHNodes

BOLT YAML profile reading time gets marginally faster (14.1572->13.9207 s) for
a large YAML profile (121MB/31K functions). Not claiming stat significance
though.

Reviewed By: hintonda

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

show more ...

Recommit [YAML IO] Check that mapping doesn't contain duplicating keys

The revert reason is fixed in D143727 (test changes).

According to YAML specification keys must be unique for a mapping node:

Recommit [YAML IO] Check that mapping doesn't contain duplicating keys

The revert reason is fixed in D143727 (test changes).

According to YAML specification keys must be unique for a mapping node:
"The content of a mapping node is an unordered set of key/value node pairs, with
the restriction that each of the keys is unique".

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

show more ...

Revert "[YAML IO] Check that mapping doesn't contain duplicating keys"

LLDB failures: https://lab.llvm.org/buildbot/#/builders/17/builds/33865

This reverts commit 4c228ee6d40a7cff256f1a680561b6c015

Revert "[YAML IO] Check that mapping doesn't contain duplicating keys"

LLDB failures: https://lab.llvm.org/buildbot/#/builders/17/builds/33865

This reverts commit 4c228ee6d40a7cff256f1a680561b6c0155ad704.

show more ...

[YAML IO] Check that mapping doesn't contain duplicating keys

According to YAML specification keys must be unique for a mapping node:
"The content of a mapping node is an unordered set of key/value

[YAML IO] Check that mapping doesn't contain duplicating keys

According to YAML specification keys must be unique for a mapping node:
"The content of a mapping node is an unordered set of key/value node pairs, with
the restriction that each of the keys is unique".

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

show more ...

YAMLParser: llvm::Optional => std::optional

[llvm][support] Replace `std::vector<bool>` use in YAMLTraits

LLVM Programmer’s Manual strongly discourages the use of `std::vector<bool>` and suggests `llvm::BitVector` as a possible replacement.

[llvm][support] Replace `std::vector<bool>` use in YAMLTraits

LLVM Programmer’s Manual strongly discourages the use of `std::vector<bool>` and suggests `llvm::BitVector` as a possible replacement.

This patch replaces the use of `std::vector` with `llvm::BitVector` in LLVM's YAML traits and replaces the call to `Vec.insert(Vec.begin(), N, false)` on empty `Vec` with `Vec.resize(N)`, which has the same semantics but avoids using `insert` and iterators, which `llvm::BitVector` doesn't possess.

Reviewed By: dexonsmith, dblaikie

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

show more ...

[NFC] Additional header dependency cleanup LLVMSupport

A few more forward-declarations, a few less headers. the impact on number of
preprocessed lines for LLVMSupport is negligible (-3K lines) but i

[NFC] Additional header dependency cleanup LLVMSupport

A few more forward-declarations, a few less headers. the impact on number of
preprocessed lines for LLVMSupport is negligible (-3K lines) but it's always
good to remove dependencies.

Related discourse thread: https://llvm.discourse.group/t/include-what-you-use-include-cleanup

show more ...

[llvm] Cleanup header dependencies in ADT and Support

The cleanup was manual, but assisted by "include-what-you-use". It consists in

1. Removing unused forward declaration. No impact expected.
2. R

[llvm] Cleanup header dependencies in ADT and Support

The cleanup was manual, but assisted by "include-what-you-use". It consists in

1. Removing unused forward declaration. No impact expected.
2. Removing unused headers in .cpp files. No impact expected.
3. Removing unused headers in .h files. This removes implicit dependencies and
is generally considered a good thing, but this may break downstream builds.
I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the
modification in the second part of the commit.
4. Replacing header inclusion by forward declaration. This has the same impact
as 3.

Notable changes:

- llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h
- llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h
- llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h
- llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h

You may need to add some of these headers in your compilation units, if needs be.

As an hint to the impact of the cleanup, running

clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l

before: 8000919 lines
after: 7917500 lines

Reduced dependencies also helps incremental rebuilds and is more ccache
friendly, something not shown by the above metric :-)

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831

show more ...

Initialize output parameters

If the function returns true, it should
set all output paremeters, similar to Output::preflightElement, or we
have UB on code like:

```
void *SaveInfo;
if (io.preflight

Initialize output parameters

If the function returns true, it should
set all output paremeters, similar to Output::preflightElement, or we
have UB on code like:

```
void *SaveInfo;
if (io.preflightFlowElement(i, SaveInfo))
io.postflightFlowElement(SaveInfo);
```

It's going to be detected by msan with:
-Xclang -enable-noundef-analysis -mllvm -msan-eager-checks=1

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

show more ...

Initialize SaveInfo in methods Output::preflightKey and Output::preflightElement.

When enabling MSAN eager mode with noundef analysis these variables were found to not be initialized in unit tests.

Initialize SaveInfo in methods Output::preflightKey and Output::preflightElement.

When enabling MSAN eager mode with noundef analysis these variables were found to not be initialized in unit tests.

Reviewed By: vitalybuka

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

show more ...

[YAML I/O] Fix bug in emission of empty sequence

Don't emit an output dash for an empty sequence. Take emitting a vector
of strings for example:

std::vector<std::string> Strings = {"foo", "bar"};

[YAML I/O] Fix bug in emission of empty sequence

Don't emit an output dash for an empty sequence. Take emitting a vector
of strings for example:

std::vector<std::string> Strings = {"foo", "bar"};
LLVM_YAML_IS_SEQUENCE_VECTOR(std::string)
yout << Strings;

This emits the following YAML document.

---
- foo
- bar
...

When the vector is empty, this generates the following result:

---
- []
...

Although this is valid YAML, it does not match what we meant to emit.
The result is a one-element sequence consisting of an empty list.
Indeed, if we were to try to read this again we get an error:

YAML:2:4: error: not a mapping
- []

The problem is the output dash before the empty list. The correct output
would be:

---
[]
...

This patch fixes that by not emitting the output dash for an empty
sequence.

Differential revision: https://reviews.llvm.org/D95280

show more ...

[YAML] Support extended spellings when parsing bools.

Support all the spellings of boolean datatypes according to https://yaml.org/type/bool.html

Reviewed By: silvas

Differential Revision: https:/

[YAML] Support extended spellings when parsing bools.

Support all the spellings of boolean datatypes according to https://yaml.org/type/bool.html

Reviewed By: silvas

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

show more ...

[YAML] Use correct source location for unknown key errors.

Currently unknown keys when inputting mapping traits have the location set to the Value.
Example:
```
YAML:1:14: error: unknown key 'Unknow

[YAML] Use correct source location for unknown key errors.

Currently unknown keys when inputting mapping traits have the location set to the Value.
Example:
```
YAML:1:14: error: unknown key 'UnknownKey'
{UnknownKey: SomeValue}
^~~~~~~~~
```
This is unhelpful for a user as it draws them to fix the wrong item.

Reviewed By: silvas

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

show more ...

Reland "[lib/Support/YAMLTraits] - Don't print leading zeroes when dumping Hex8/Hex16/Hex32 types." (https://reviews.llvm.org/D90930).

This reverts reverting commit fc40a03323a4b265ccbed34a07e281b13

Reland "[lib/Support/YAMLTraits] - Don't print leading zeroes when dumping Hex8/Hex16/Hex32 types." (https://reviews.llvm.org/D90930).

This reverts reverting commit fc40a03323a4b265ccbed34a07e281b13c5e8367
and fixes LLD (MachO/wasm) tests that failed previously.

show more ...

Revert "[lib/Support/YAMLTraits] - Don't print leading zeroes when dumping Hex8/Hex16/Hex32 types."

This reverts commit 65fd17c241e22e1671e81efdb683687369c2feb3.

It breaks LLD/MachO tests that seem

Revert "[lib/Support/YAMLTraits] - Don't print leading zeroes when dumping Hex8/Hex16/Hex32 types."

This reverts commit 65fd17c241e22e1671e81efdb683687369c2feb3.

It breaks LLD/MachO tests that seems use obj2yaml the check the output.

show more ...

[lib/Support/YAMLTraits] - Don't print leading zeroes when dumping Hex8/Hex16/Hex32 types.

When we produce an YAML output, we also print leading zeroes currently.
An output might look like this:

``

[lib/Support/YAMLTraits] - Don't print leading zeroes when dumping Hex8/Hex16/Hex32 types.

When we produce an YAML output, we also print leading zeroes currently.
An output might look like this:

```
- Name: .dynsym
Type: SHT_DYNSYM
Address: 0x0000000000001000
EntSize: 0x0000000000000018
```

There are probably no reason to print leading zeroes.
It just makes harder to read values. This patch stops printing them.
The output becomes like:

```
- Name: .dynsym
Type: SHT_DYNSYM
Address: 0x1000
EntSize: 0x18
```

This affects obj2yaml mostly, but also dsymutil and llvm-xray tools output.

Differential revision: https://reviews.llvm.org/D90930

show more ...

[llvm] Fix ODRViolations for VersionTuple YAML specializations NFC

It appears for Swift there was confusing errors when trying to parse APINotes, when libAPINotes and libInterfaceStub are linked, th

[llvm] Fix ODRViolations for VersionTuple YAML specializations NFC

It appears for Swift there was confusing errors when trying to parse APINotes, when libAPINotes and libInterfaceStub are linked, they both export symbol
`__ZN4llvm4yaml7yamlizeINS_12VersionTupleEEENSt3__19enable_ifIXsr16has_ScalarTraitsIT_EE5valueEvE4typeERNS0_2IOERS5_bRNS0_12EmptyContextE`, and discovered
same symbol defined within llvm-ifs.

This consolidates the boilerplate into YAMLTraits and defers the specific validation in reading the whole input.
fixes: rdar://problem/70450563

Reviewed By: phosek, dblaikie

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

show more ...

Add -Wno-error=unknown flag to clang-format.

Currently newer clang-format options cannot be included in .clang-format files, if not all users can be forced to use an updated version.
This patch trie

Add -Wno-error=unknown flag to clang-format.

Currently newer clang-format options cannot be included in .clang-format files, if not all users can be forced to use an updated version.
This patch tries to solve this by adding an option to clang-format, enabling to ignore unknown (newer) options.

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

show more ...