[C++20] [Modules] Disable preferred_name when writing a C++20 Module interface

Currently, the use of preferred_name would block implementing std
modules in libcxx. See https://github.com/llvm/llvm-p

[C++20] [Modules] Disable preferred_name when writing a C++20 Module interface

Currently, the use of preferred_name would block implementing std
modules in libcxx. See https://github.com/llvm/llvm-project/issues/56490
for example.
The problem is pretty hard and it looks like we couldn't solve it in a
short time. So we sent this patch as a workaround to avoid blocking us
to modularize STL. This is intended to be fixed properly in the future.

Reviewed By: erichkeane, aaron.ballman, tahonermann

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

show more ...

[Support] Change compression::zlib::{compress,uncompress} to use uint8_t *

It's more natural to use uint8_t * (std::byte needs C++17 and llvm has
too much uint8_t *) and most callers use uint8_t * i

[Support] Change compression::zlib::{compress,uncompress} to use uint8_t *

It's more natural to use uint8_t * (std::byte needs C++17 and llvm has
too much uint8_t *) and most callers use uint8_t * instead of char *.
The functions are recently moved into `llvm::compression::zlib::`, so
downstream projects need to make adaption anyway.

show more ...

[clang, clang-tools-extra] Use has_value instead of hasValue (NFC)

[NFC] Refactor llvm::zlib namespace

* Refactor compression namespaces across the project, making way for a possible
introduction of alternatives to zlib compression.
Changes are as follows:
*

[NFC] Refactor llvm::zlib namespace

* Refactor compression namespaces across the project, making way for a possible
introduction of alternatives to zlib compression.
Changes are as follows:
* Relocate the `llvm::zlib` namespace to `llvm::compression::zlib`.

Reviewed By: MaskRay, leonardchan, phosek

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

show more ...

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[clang] Don't use Optional::hasValue (NFC)

Revert "[OpenMP] atomic compare fail : Parser & AST support"

This reverts commit 232bf8189ef7d574a468bd5bfd1e84e962f7f16e.

It broke the sanitize buildbot: https://lab.llvm.org/buildbot/#/builders/5

Revert "[OpenMP] atomic compare fail : Parser & AST support"

This reverts commit 232bf8189ef7d574a468bd5bfd1e84e962f7f16e.

It broke the sanitize buildbot: https://lab.llvm.org/buildbot/#/builders/5/builds/24074

It also reproduces on Windows debug builds as a crash.

show more ...

[OpenMP] atomic compare fail : Parser & AST support

This is a support for " #pragma omp atomic compare fail ". It has Parser & AST support for now.

Reviewed By: tianshilei1992

Differential Revisio

[OpenMP] atomic compare fail : Parser & AST support

This is a support for " #pragma omp atomic compare fail ". It has Parser & AST support for now.

Reviewed By: tianshilei1992

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

show more ...

[OpenMP] Add parsing/sema support for omp_all_memory reserved locator

Adds support for the reserved locator 'omp_all_memory' for use
in depend clauses with 'out' or 'inout' dependence-types.

Differ

[OpenMP] Add parsing/sema support for omp_all_memory reserved locator

Adds support for the reserved locator 'omp_all_memory' for use
in depend clauses with 'out' or 'inout' dependence-types.

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

show more ...

[Serialization] Delta encode locations in expansion sloc entries

This is a 1.9% reduction in PCH size in my measurements.

In abbreviated records, VBR6 seems to be slightl better than VBR8 for locat

[Serialization] Delta encode locations in expansion sloc entries

This is a 1.9% reduction in PCH size in my measurements.

In abbreviated records, VBR6 seems to be slightl better than VBR8 for locations
that may be delta-encoded (i.e. not the first)

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

show more ...

[Serialization] Delta-encode consecutive SourceLocations in TypeLoc

Much of the size of PCH/PCM files comes from stored SourceLocations.
These are encoded using (almost) their raw value, VBR-encoded

[Serialization] Delta-encode consecutive SourceLocations in TypeLoc

Much of the size of PCH/PCM files comes from stored SourceLocations.
These are encoded using (almost) their raw value, VBR-encoded. Absolute
SourceLocations can be relatively large numbers, so this commonly takes
20-30 bits per location.

We can reduce this by exploiting redundancy: many "nearby" SourceLocations are
stored differing only slightly and can be delta-encoded.
Randam-access loading of AST nodes constrains how long these sequences
can be, but we can do it at least within a node that always gets
deserialized as an atomic unit.

TypeLoc is implemented in this patch as it's a relatively small change
that shows most of the API.
This saves ~3.5% of PCH size, I have local changes applying this technique
further that save another 3%, I think it's possible to get to 10% total.

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

show more ...

[clang] serialize ORIGINAL_PCH_DIR relative to BaseDirectory

This diff changes the serialization of the `ORIGINAL_PCH_DIR`
entry in module files to be serialized relative to the module's
`BaseDirect

[clang] serialize ORIGINAL_PCH_DIR relative to BaseDirectory

This diff changes the serialization of the `ORIGINAL_PCH_DIR`
entry in module files to be serialized relative to the module's
`BaseDirectory`. This will allow for the module to be relocatable
across machines.

The path is restored relative to the module's BaseDirectory on
deserialization.

Reviewed By: urnathan

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

show more ...

[clang] serialize SUBMODULE_TOPHEADER relative to BaseDirectory

This diff changes the serialization of the `SUBMODULE_TOPHEADER`
entry in module files to be serialized relative to the module's
`Base

[clang] serialize SUBMODULE_TOPHEADER relative to BaseDirectory

This diff changes the serialization of the `SUBMODULE_TOPHEADER`
entry in module files to be serialized relative to the module's
`BaseDirectory`. This matches the behavior of the
`SUBMODULE_HEADER` entry and will allow for the module to be
relocatable across machines.

The path is restored relative to the module's `BaseDirectory` on
deserialization.

Reviewed By: urnathan

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

show more ...

[clang] add -fmodule-file-home-is-cwd

This diff adds a new frontend flag `-fmodule-file-home-is-cwd`.
The behavior of this flag is similar to
`-fmodule-map-file-home-is-cwd` but does not require the

[clang] add -fmodule-file-home-is-cwd

This diff adds a new frontend flag `-fmodule-file-home-is-cwd`.
The behavior of this flag is similar to
`-fmodule-map-file-home-is-cwd` but does not require the module
map files to be modified to have inputs relative to the cwd.
Instead the output modules will have their `BaseDirectory` set
to the cwd and will try and resolve paths relative to that.

The motiviation for this change is to support relocatable pcm
files that are built on different machines with different paths
without having to alter module map files, which is sometimes not
possible as they are provided by 3rd parties.

Reviewed By: urnathan

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

show more ...

[RFC] Add and sort decl to maintain order instead of inserting in order

ASTWriter::associateDeclWithFile shows a lot in clangd perf profile due to O(n^2) behaviour in insertion of DeclIDs in SortedF

[RFC] Add and sort decl to maintain order instead of inserting in order

ASTWriter::associateDeclWithFile shows a lot in clangd perf profile due to O(n^2) behaviour in insertion of DeclIDs in SortedFileDeclIDs. Instead of doing that, this patch just appends it to the DeclIDs vector and sorts them at the end.

Reviewed By: akyrtzi

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

show more ...

[Serialization] Remove dead TYPE_FUNCTION_PROTO abbreviation. NFC

It was added in 01b2cb47 but never used.

[clang][OpenMP5.1] Initial parsing/sema for has_device_addr

Added basic parsing/sema/ support for the 'has_device_addr' clause.

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

[Support/Hash functions] Change the `final()` and `result()` of the hashing functions to return an array of bytes

Returning `std::array<uint8_t, N>` is better ergonomics for the hashing functions us

[Support/Hash functions] Change the `final()` and `result()` of the hashing functions to return an array of bytes

Returning `std::array<uint8_t, N>` is better ergonomics for the hashing functions usage, instead of a `StringRef`:

* When returning `StringRef`, client code is "jumping through hoops" to do string manipulations instead of dealing with fixed array of bytes directly, which is more natural
* Returning `std::array<uint8_t, N>` avoids the need for the hasher classes to keep a field just for the purpose of wrapping it and returning it as a `StringRef`

As part of this patch also:

* Introduce `TruncatedBLAKE3` which is useful for using BLAKE3 as the hasher type for `HashBuilder` with non-default hash sizes.
* Make `MD5Result` inherit from `std::array<uint8_t, 16>` which improves & simplifies its API.

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

show more ...

Serialize PragmaAssumeNonNullLoc to support preambles

Previously, if a `#pragma clang assume_nonnull begin` was at the
end of a premable with a `#pragma clang assume_nonnull end` at the
end of the m

Serialize PragmaAssumeNonNullLoc to support preambles

Previously, if a `#pragma clang assume_nonnull begin` was at the
end of a premable with a `#pragma clang assume_nonnull end` at the
end of the main file, clang would diagnose an unterminated begin in
the preamble and an unbalanced end in the main file.

With this change, those errors no longer occur and the case above is
now properly handled. I've added a corresponding test to clangd,
which makes use of preambles, in order to verify this works as
expected.

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

show more ...

[C++20][Modules][HU 3/5] Emit module macros for header units.

For header units we build the top level module directly from the header
that it represents and macros defined in this TU need to be emit

[C++20][Modules][HU 3/5] Emit module macros for header units.

For header units we build the top level module directly from the header
that it represents and macros defined in this TU need to be emitted (when
such a definition is live at the end of the TU).

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

show more ...

[Clang] Fix Unevaluated Lambdas

Unlike other types, when lambdas are instanciated,
they are recreated from scratch.
When an unevaluated lambdas appear in the type of a function,
parameter it is inst

[Clang] Fix Unevaluated Lambdas

Unlike other types, when lambdas are instanciated,
they are recreated from scratch.
When an unevaluated lambdas appear in the type of a function,
parameter it is instanciated in the wrong declaration context,
as parameters are transformed before the function.

To support lambda in function parameters, we try to
compute whether they are dependant without looking at the
declaration context.

This is a short term stopgap solution to avoid clang
iceing. A better fix might be to inject some kind of
transparent declaration with correctly computed dependency
for function parameters, variable templates, etc.

Fixes https://github.com/llvm/llvm-project/issues/50376
Fixes https://github.com/llvm/llvm-project/issues/51414
Fixes https://github.com/llvm/llvm-project/issues/51416
Fixes https://github.com/llvm/llvm-project/issues/51641
Fixes https://github.com/llvm/llvm-project/issues/54296

Reviewed By: aaron.ballman

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

show more ...

[Clang] Work with multiple pragmas weak before definition

Update `WeakUndeclaredIdentifiers` to hold a collection of weak
aliases per identifier instead of only one.

This also allows the "used" sta

[Clang] Work with multiple pragmas weak before definition

Update `WeakUndeclaredIdentifiers` to hold a collection of weak
aliases per identifier instead of only one.

This also allows the "used" state to be removed from `WeakInfo`
because it is really only there as an alternative to removing
processed map entries, and we can represent that using an empty set
now. The serialization code is updated for the removal of the field.
Additionally, a PCH test is added for the new functionality.

The records are grouped by the "target" identifier, which was already
being used as a key for lookup purposes. We also store only one record
per alias name; combined, this means that diagnostics are grouped by
the "target" and limited to one per alias (which should be acceptable).

Fixes PR28611.
Fixes llvm/llvm-project#28985.

Reviewed By: aaron.ballman, cebowleratibm

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

Co-authored-by: Rachel Craik <[email protected]>
Co-authored-by: Jamie Schmeiser <[email protected]>

show more ...

Use llvm::append_range instead of push_back loops where applicable. NFCI.

[Attr] Fix a btf_type_tag AST generation

Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note.

[Attr] Fix a btf_type_tag AST generation

Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note. But this is not enough for btf_type_tag
as the attribute might have the same ModifiedType and EquivType, but
still have different string associated with attribute.

For example, for a data structure like below,
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b;
};
The current ASTContext.getAttributedType() will produce
an AST similar to below:
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *b;
};
and this is incorrect.

It is very difficult to use the current AttributedType as it is hard to
get the tag information. To fix the problem, this patch introduced
BTFTagAttributedType which is similar to AttributedType
in many ways but with an additional BTFTypeTagAttr. The tag itself can
be retrieved with BTFTypeTagAttr.
With the new BTFTagAttributed type, the debuginfo code can be greatly
simplified compared to previous TypeLoc based approach.

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

show more ...