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

[yaml][clang-tidy] Fix multiline YAML serialization

Summary:
New line duplication logic introduced in https://reviews.llvm.org/D63482
has two issues: (1) there is no logic that removes duplicate new

[yaml][clang-tidy] Fix multiline YAML serialization

Summary:
New line duplication logic introduced in https://reviews.llvm.org/D63482
has two issues: (1) there is no logic that removes duplicate newlines
when clang-apply-replacment reads YAML and (2) in general such logic
should be applied to all strings and should happen on string
serialization level instead in YAML parser.

This diff changes multiline strings quotation from single quote `'` to
double `"`. It solves problems with internal newlines because now they are
escaped. Also double quotation solves the problem with leading whitespace after
newline. In case of single quotation YAML parsers should remove leading
whitespace according to specification. In case of double quotation these
leading are internal space and they are preserved. There is no way to
instruct YAML parsers to preserve leading whitespaces after newline so
double quotation is the only viable option that solves all problems at
once.

Test Plan: check-all

Reviewers: gribozavr, mgehre, yvvan

Subscribers: xazax.hun, hiraditya, cfe-commits, llvm-commits

Tags: #clang-tools-extra, #clang, #llvm

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

show more ...

[yaml2obj][MachO] - Fix PubName/PubType handling.

`PubName` and `PubType` are optional fields since D80722.

They are defined as:
Optional<PubSection> PubNames;
Optional<PubSection> PubTypes;

A

[yaml2obj][MachO] - Fix PubName/PubType handling.

`PubName` and `PubType` are optional fields since D80722.

They are defined as:
Optional<PubSection> PubNames;
Optional<PubSection> PubTypes;

And initialized in the following way:
IO.mapOptional("debug_pubnames", DWARF.PubNames);
IO.mapOptional("debug_pubtypes", DWARF.PubTypes);

But problem is that because of the issue in `YAMLTraits.cpp`,
when there are no `debug_pubnames`/`debug_pubtypes` keys in a YAML description,
they are not initialized to `Optional::None` as the code expects, but they
are initialized to default `PubSection()` instances.

Because of this, the `if` condition in the following code is always true:

if (Obj.DWARF.PubNames)
Err = DWARFYAML::emitPubSection(OS, *Obj.DWARF.PubNames,
Obj.IsLittleEndian);

What means `emitPubSection` is always called and it writes few values.

This patch fixes the issue. I've reduced `sizeofcmds` by size of data
previously written because of this bug.

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

show more ...

[YAMLTraits] Remove char trait and serialize as uint8_t in lldb.

As discussed in https://reviews.llvm.org/D79745

Revert "Revert "[YAMLTraits] Add trait for char""

Reverting this to unblock all the LLDB bots while we try to figure out a
solution for Solaris in https://reviews.llvm.org/D79745.

Revert "[YAMLTraits] Add trait for char"

This reverts commit fab08bf4899e40d02d8bf394a63499ac679ac61c. It has left
the Solaris buildbots broken for a week and a half as reported
in https://reviews.

Revert "[YAMLTraits] Add trait for char"

This reverts commit fab08bf4899e40d02d8bf394a63499ac679ac61c. It has left
the Solaris buildbots broken for a week and a half as reported
in https://reviews.llvm.org/D79745.

show more ...

[YAMLTraits] Add trait for char

Add a YAML trait for char.

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

[NFC] Corrected a minor typo in a comment

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...

Remove redundant "std::move"s in return statements

YAML parser robustness improvements

Summary: This patch fixes a number of bugs found in the YAML parser
through fuzzing. In general, this makes the parser more robust against
malformed inputs.

The

YAML parser robustness improvements

Summary: This patch fixes a number of bugs found in the YAML parser
through fuzzing. In general, this makes the parser more robust against
malformed inputs.

The fixes are mostly improved null checking and returning errors in
more cases. In some cases, asserts were changed to regular errors,
this provides the same robustness but also protects release builds
from the triggering conditions. This also improves the fuzzability of
the YAML parser since asserts can act as a roadblock to further
fuzzing once they're hit.

Each fix has a corresponding test case:
- TestAnchorMapError - Added proper null pointer handling in
`Stream::printError` if N is null and `KeyValueNode::getValue` if
getKey returns null, `Input::createHNodes` `dyn_casts` changed to
`dyn_cast_or_null` so the null pointer checks are actually able to
fail
- TestFlowSequenceTokenErrors - Added case in
`Document::parseBlockNode` for FlowMappingEnd, FlowSequenceEnd, or
FlowEntry tokens outside of mappings or sequences
- TestDirectiveMappingNoValue - Changed assert to regular error
return in `Scanner::scanValue`
- TestUnescapeInfiniteLoop - Fixed infinite loop in
`ScalarNode::unescapeDoubleQuoted` by returning an error for
unrecognized escape codes
- TestScannerUnexpectedCharacter - Changed asserts to regular error
returns in `Scanner::consume`
- TestUnknownDirective - For both of the inputs the stream doesn't
fail and correctly returns TK_Error, but there is no valid root
node for the document. There's no reasonable way to make the
scanner fail for unknown directives without breaking the YAML spec
(see spec-07-01.test). I think the assert is unnecessary given
that an error is still generated for this case.

The `SimpleKeys.clear()` line fixes a bug found by AddressSanitizer
triggered by multiple test cases - when TokenQueue is cleared
SimpleKeys is still holding dangling pointers into it, so SimpleKeys
should be cleared as well.

Patch by Thomas Finch!

Reviewers: chandlerc, Bigcheese, hintonda

Reviewed By: Bigcheese, hintonda

Subscribers: hintonda, kristina, beanz, dexonsmith, hiraditya, llvm-commits

Tags: #llvm

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

show more ...

[yaml2obj][obj2yaml] - Use a single "Other" field instead of "Other", "Visibility" and "StOther".

Currenly we can encode the 'st_other' field of symbol using 3 fields.
'Visibility' is used to encode

[yaml2obj][obj2yaml] - Use a single "Other" field instead of "Other", "Visibility" and "StOther".

Currenly we can encode the 'st_other' field of symbol using 3 fields.
'Visibility' is used to encode STV_* values.
'Other' is used to encode everything except the visibility, but it can't handle arbitrary values.
'StOther' is used to encode arbitrary values when 'Visibility'/'Other' are not helpfull enough.

'st_other' field is used to encode symbol visibility and platform-dependent
flags and values. Problem to encode it is that it consists of Visibility part (STV_* values)
which are enumeration values and the Other part, which is different and inconsistent.

For MIPS the Other part contains flags for all STO_MIPS_* values except STO_MIPS_MIPS16.
(Like comment in ELFDumper says: "Someones in their infinite wisdom decided to make
STO_MIPS_MIPS16 flag overlapped with other ST_MIPS_xxx flags."...)

And for PPC64 the Other part might actually encode any value.

This patch implements custom logic for handling the st_other and removes
'Visibility' and 'StOther' fields.

Here is an example of a new YAML style this patch allows:

- Name: foo
Other: [ 0x4 ]
- Name: bar
Other: [ STV_PROTECTED, 4 ]
- Name: zed
Other: [ STV_PROTECTED, STO_MIPS_OPTIONAL, 0xf8 ]

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

llvm-svn: 370472

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...