[JSON] Export sortedElements and fix CLANGD_TRACE non-determinism

clangd/test/trace.test might fail as llvm::hash_value(StringRef) is
non-deterministic per process (#96282).

[ASan][JSON] Unpoison memory before its reuse (#79065)

This commit unpoisons memory before its reuse (with reinterpret_cast).
Required by https://github.com/llvm/llvm-project/pull/79049

Notice t

[ASan][JSON] Unpoison memory before its reuse (#79065)

This commit unpoisons memory before its reuse (with reinterpret_cast).
Required by https://github.com/llvm/llvm-project/pull/79049

Notice that it's a temporary solution to prevent buildbots from failing.
Read FIXME for details.

show more ...

[Support] Apply fixes from modernize-type-trait (NFC)

[support] Provide overload to PrintNumber that use C++ types

This attempts to address an issue with overload resolution for `PrintNumber`
with `size_t` parameters on Darwin, brought up in
https://re

[support] Provide overload to PrintNumber that use C++ types

This attempts to address an issue with overload resolution for `PrintNumber`
with `size_t` parameters on Darwin, brought up in
https://reviews.llvm.org/D146492.

On Aarch64 Darwin, `uint64_t` has a different typedef than `size_t`
(e.g., `unsigned long long` vs. `unsigned long`), whereas on Linux and
Windows they are the same.

This commit also reverts the static_cast's added in
064e2497e2ebe9ac30ac96923a26a52484300fdf, since they are no longer
needed.

Reviewed By: jhenderson

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

show more ...

[JSON] Fix uninitialized variable warning

Fix uninitialized variable warning when deserializing a std::optional<E>
where is an enum type.

JSON.h:771:20: warning: variable 'Result' is uninitialized

[JSON] Fix uninitialized variable warning

Fix uninitialized variable warning when deserializing a std::optional<E>
where is an enum type.

JSON.h:771:20: warning: variable 'Result' is uninitialized when used here [-Wuninitialized]
if (!fromJSON(E, Result, P))
^~~~~~

show more ...

Remove a workaround for libstdc++4.8

Reviewed By: nikic

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

JSON: llvm::Optional => std::optional

Many files are from language servers.

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[llvm] Use std::nullopt instead of None in comments (NFC)

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

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalu

[llvm] Use std::nullopt instead of None in comments (NFC)

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

[ADT, Support] 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 amou

[ADT, Support] 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

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

show more ...

[iwyu] Move <cmath> out of llvm/Support/MathExtras.h

Interestingly, MathExtras.h doesn't use <cmath> declaration, so move it out of
that header and include it when needed.

No functional change inte

[iwyu] Move <cmath> out of llvm/Support/MathExtras.h

Interestingly, MathExtras.h doesn't use <cmath> declaration, so move it out of
that header and include it when needed.

No functional change intended, but there's no longer a transitive include
fromMathExtras.h to cmath.

show more ...

Revert "Use std::is_same_v instead of std::is_same (NFC)"

This reverts commit c5da37e42d388947a40654b7011f2a820ec51601.

This patch seems to break builds with some versions of MSVC.

Use std::is_same_v instead of std::is_same (NFC)

[llvm] Fix forward declaration in Support/JSON.h

Some methods of json::Array require json::Value to be completely defined, so
they can't be defined in-class. Fix that by defining them out of class.

[llvm] Fix forward declaration in Support/JSON.h

Some methods of json::Array require json::Value to be completely defined, so
they can't be defined in-class. Fix that by defining them out of class.

Fix #55780

show more ...

Move STLFunctionalExtras out of STLExtras

Only using that change in StringRef already decreases the number of
preoprocessed lines from 7837621 to 7776151 for LLVMSupport

Perhaps more interestingly,

Move STLFunctionalExtras out of STLExtras

Only using that change in StringRef already decreases the number of
preoprocessed lines from 7837621 to 7776151 for LLVMSupport

Perhaps more interestingly, it shows that many files were relying on the
inclusion of StringRef.h to have the declaration from STLExtras.h. This
patch tries hard to patch relevant part of llvm-project impacted by this
hidden dependency removal.

Potential impact:
- "llvm/ADT/StringRef.h" no longer includes <memory>,
"llvm/ADT/Optional.h" nor "llvm/ADT/STLExtras.h"

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

show more ...

[JSON] Handle uint64_t type

There was no handling of uint64_t in the LLVM JSON library.
This patch adds support for that. The motivation is
the https://reviews.llvm.org/D109217.

Differential Revisi

[JSON] Handle uint64_t type

There was no handling of uint64_t in the LLVM JSON library.
This patch adds support for that. The motivation is
the https://reviews.llvm.org/D109217.

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

show more ...

Revert "ADT: Migrate users of AlignedCharArrayUnion to std::aligned_union_t, NFC"

We determined that the MSVC implementation of std::aligned* isn't suited
to our needs. It doesn't support 16 byte al

Revert "ADT: Migrate users of AlignedCharArrayUnion to std::aligned_union_t, NFC"

We determined that the MSVC implementation of std::aligned* isn't suited
to our needs. It doesn't support 16 byte alignment or higher, and it
doesn't really guarantee 8 byte alignment. See
https://github.com/microsoft/STL/issues/1533

Also reverts "ADT: Change AlignedCharArrayUnion to an alias of std::aligned_union_t, NFC"

Also reverts "ADT: Remove AlignedCharArrayUnion, NFC" to bring back
AlignedCharArrayUnion.

This reverts commit 4d8bf870a82765eb0d4fe53c82f796b957c05954.

This reverts commit d10f9863a5ac1cb681af07719650c44b48f289ce.

This reverts commit 4b5dc150b9862271720b3d56a3e723a55dd81838.

show more ...

ADT: Migrate users of AlignedCharArrayUnion to std::aligned_union_t, NFC

Prepare to delete `AlignedCharArrayUnion` by migrating its users over to
`std::aligned_union_t`.

I will delete `AlignedCharA

ADT: Migrate users of AlignedCharArrayUnion to std::aligned_union_t, NFC

Prepare to delete `AlignedCharArrayUnion` by migrating its users over to
`std::aligned_union_t`.

I will delete `AlignedCharArrayUnion` and its tests in a follow-up
commit so that it's easier to revert in isolation in case some
downstream wants to keep using it.

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

show more ...

ADT: Stop peeking inside AlignedCharArrayUnion, NFC

Update all the users of `AlignedCharArrayUnion` to stop peeking inside
(to look at `buffer`) so that a follow-up patch can replace it with an
alia

ADT: Stop peeking inside AlignedCharArrayUnion, NFC

Update all the users of `AlignedCharArrayUnion` to stop peeking inside
(to look at `buffer`) so that a follow-up patch can replace it with an
alias to `std::aligned_union_t`.

This was reviewed as part of https://reviews.llvm.org/D92512, but I'm
splitting this bit out to commit first to reduce churn in case the
change to `AlignedCharArrayUnion` needs to be reverted for some
unexpected reason.

show more ...

[JSON] Add ObjectMapper::mapOptional to validate optional data.

Currently the idiom for mapping optional fields is:
ObjectMapper O(Val, P);
if (!O.map("required1", Out.R1) || !O.map("required2",

[JSON] Add ObjectMapper::mapOptional to validate optional data.

Currently the idiom for mapping optional fields is:
ObjectMapper O(Val, P);
if (!O.map("required1", Out.R1) || !O.map("required2", Out.R2))
return false;
O.map("optional1", Out.O1); // ignore result
return true;

If `optional1` is present but malformed, then we won't detect/report
that error. We may even leave `Out` in an incomplete state while returning true.
Instead, we'd often prefer to ignore `optional1` if it is absent, but otherwise
behave just like map().

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

show more ...

[json] Provide a means to delegate writing a value to another API

(Based on D87170 by dsanders)

I recently had need to call out to an external API to emit a JSON object as part
of one an LLVM tool

[json] Provide a means to delegate writing a value to another API

(Based on D87170 by dsanders)

I recently had need to call out to an external API to emit a JSON object as part
of one an LLVM tool was emitting. However, our JSON support didn't provide a way
to delegate part of the JSON output to that API.

Add rawValueBegin() and rawValueEnd() to maintain and check the internal state
while something else is writing to the stream. It's the users responsibility to
ensure that the resulting JSON output is still valid.

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

show more ...

[JSON] Add error reporting to fromJSON and ObjectMapper

Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
c

[JSON] Add error reporting to fromJSON and ObjectMapper

Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".

The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);

Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.

I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).

All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.

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

show more ...

[JSON] Display errors associated with Paths in context

When an error occurs processing a JSON object, seeing the actual
surrounding data helps. Dumping just the node where the problem
was identified

[JSON] Display errors associated with Paths in context

When an error occurs processing a JSON object, seeing the actual
surrounding data helps. Dumping just the node where the problem
was identified can be too much or too little information.

printErrorContext() shows the error message in its context, as a comment.
JSON values along the path to the broken place are shown in some detail,
the rest of the document is elided. For example:

```
{
"credentials": [
{
"username": /* error: expected string */ 42,
"password": "secret"
},
{ ... }
]
"backups": { ... }
}
```

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

show more ...

[JSON] Facility to track position within an object and report errors.

This error model should be rich enough for most applications. It comprises:

- a name for the root object, so the user knows wha

[JSON] Facility to track position within an object and report errors.

This error model should be rich enough for most applications. It comprises:

- a name for the root object, so the user knows what we're parsing
- a path from the root object to the JSON node most associated with the error
- a local error message

This can be presented as an llvm::Error e.g.
"expected string at ConfigFile.credentials[0].username"

It's designed to be cheap: Paths are a linked list of lightweight
objects on the stack. No heap allocations unless errors are encountered.

A subsequent commit will make use of this in the JSON-to-object
translation facilities: fromJSON and ObjectMapper.
However it's independent of these and can be used for e.g. validation alone.

Another subsequent commit will support showing the error in its context
within the parsed value.

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

show more ...

[JSON] Allow emitting comments in json::OStream

This isn't standard JSON, but is a popular extension.
It will be used to show errors in context, rendering pseudo-json for humans.

Differential Revis

[JSON] Allow emitting comments in json::OStream

This isn't standard JSON, but is a popular extension.
It will be used to show errors in context, rendering pseudo-json for humans.

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

show more ...

Use std::foo_t rather than std::foo in LLVM.

Summary: C++14 migration. No functional change.

Reviewers: bkramer, JDevlieghere, lebedev.ri

Subscribers: MatzeB, hiraditya, jkorous, dexonsmith, arpha

Use std::foo_t rather than std::foo in LLVM.

Summary: C++14 migration. No functional change.

Reviewers: bkramer, JDevlieghere, lebedev.ri

Subscribers: MatzeB, hiraditya, jkorous, dexonsmith, arphaman, kadircet, lebedev.ri, usaxena95, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...