[clang-repl] Simplify the value printing logic to enable out-of-process. (#107737)

This patch improves the design of the IncrementalParser and Interpreter
classes. Now the incremental parser is onl

[clang-repl] Simplify the value printing logic to enable out-of-process. (#107737)

This patch improves the design of the IncrementalParser and Interpreter
classes. Now the incremental parser is only responsible for building the
partial translation unit declaration and the AST, while the Interpreter
fills in the lower level llvm::Module and other JIT-related
infrastructure. Finally the Interpreter class now orchestrates the AST
and the LLVM IR with the IncrementalParser and IncrementalExecutor
classes.

The design improvement allows us to rework some of the logic that
extracts an interpreter value into the clang::Value object. The new
implementation simplifies use-cases which are used for out-of-process
execution by allowing interpreter to be inherited or customized with an
clang::ASTConsumer.

This change will enable completing the pretty printing work which is in
llvm/llvm-project#84769

show more ...

[Serialization] Add a callback to register new created predefined decls for DeserializationListener (#102855)

Close https://github.com/llvm/llvm-project/issues/102684

The root cause of the issue

[Serialization] Add a callback to register new created predefined decls for DeserializationListener (#102855)

Close https://github.com/llvm/llvm-project/issues/102684

The root cause of the issue is, it is possible that the predefined decl
is not registered at the beginning of writing a module file but got
created during the process of writing from reading.

This is incorrect. The predefined decls should always be predefined
decls.

Another deep thought about the issue is, we shouldn't read any new
things after we start to write the module file. But this is another
deeper question.

show more ...

[BPF] Fix linking issues in static map initializers (#91310)

When BPF object files are linked with bpftool, every symbol must be
accompanied by BTF info. Ensure that extern functions referenced by

[BPF] Fix linking issues in static map initializers (#91310)

When BPF object files are linked with bpftool, every symbol must be
accompanied by BTF info. Ensure that extern functions referenced by
global variable initializers are included in BTF.

The primary motivation is "static" initialization of PROG maps:

```c
extern int elsewhere(struct xdp_md *);

struct {
__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
__uint(max_entries, 1);
__type(key, int);
__type(value, int);
__array(values, int (struct xdp_md *));
} prog_map SEC(".maps") = { .values = { elsewhere } };
```

BPF backend needs debug info to produce BTF. Debug info is not
normally generated for external variables and functions. Previously, it
was solved differently for variables (collecting variable declarations
in ExternalDeclarations vector) and functions (logic invoked during
codegen in CGExpr.cpp).

This patch generalises ExternalDefclarations to include both function
and variable declarations. This change ensures that function references
are not missed no matter the context. Previously external functions
referenced in constant expressions lacked debug info.

show more ...

[NFC] [Serialization] Merge IdentID with IdentifierID

In ASTBitCodes.h, there are two type alias for the ID type of
Identifiers with the same underlying type. It is confusing. This patch
tries to me

[NFC] [Serialization] Merge IdentID with IdentifierID

In ASTBitCodes.h, there are two type alias for the ID type of
Identifiers with the same underlying type. It is confusing. This patch
tries to merge the `IdentID` to `IdentifierID` to erase such confusion.

show more ...

[NFC] [Serialization] Avoid using DeclID directly as much as possible

This patch tries to remove all the direct use of DeclID except the real
low level reading and writing. All the use of DeclID is

[NFC] [Serialization] Avoid using DeclID directly as much as possible

This patch tries to remove all the direct use of DeclID except the real
low level reading and writing. All the use of DeclID is converted to
the use of LocalDeclID or GlobalDeclID. This is helpful to increase the
readability and type safety.

show more ...

Revert "[NFC] [Serialization] Avoid using DeclID directly as much as possible"

This reverts commit 42070a5c092ed420bf92ebf38229c594885e94c7.

I forgot to touch lldb.

[NFC] [Serialization] Avoid using DeclID directly as much as possible

This patch tries to remove all the direct use of DeclID except the real
low level reading and writing. All the use of DeclID is

[NFC] [Serialization] Avoid using DeclID directly as much as possible

This patch tries to remove all the direct use of DeclID except the real
low level reading and writing. All the use of DeclID is converted to
the use of LocalDeclID or GlobalDeclID. This is helpful to increase the
readability and type safety.

show more ...

[NFC] Move DeclID from serialization/ASTBitCodes.h to AST/DeclID.h (#89873)

Previously, the DeclID is defined in serialization/ASTBitCodes.h under
clang::serialization namespace. However, actually

[NFC] Move DeclID from serialization/ASTBitCodes.h to AST/DeclID.h (#89873)

Previously, the DeclID is defined in serialization/ASTBitCodes.h under
clang::serialization namespace. However, actually the DeclID is not
purely used in serialization part. The DeclID is already widely used in
AST and all around the clang project via classes like `LazyPtrDecl` or
calling `ExternalASTSource::getExernalDecl()`. All such uses are via the
raw underlying type of `DeclID` as `uint32_t`. This is not pretty good.

This patch moves the DeclID class family to a new header `AST/DeclID.h`
so that the whole project can use the wrapped class `DeclID`,
`GlobalDeclID` and `LocalDeclID` instead of the raw underlying type.
This can improve the readability and the type safety.

show more ...

[C++20] [Modules] Avoid writing untouched DeclUpdates from GMF in
Reduced BMI

Mitigate https://github.com/llvm/llvm-project/issues/61447

The root cause of the above problem is that when we write a

[C++20] [Modules] Avoid writing untouched DeclUpdates from GMF in
Reduced BMI

Mitigate https://github.com/llvm/llvm-project/issues/61447

The root cause of the above problem is that when we write a declaration,
we need to lookup all the redeclarations in the imported modules. Then
it will be pretty slow if there are too many redeclarations in different
modules. This patch doesn't solve the porblem.

What the patchs mitigated is, when we writing a named module, we shouldn't
write the declarations from GMF if it is unreferenced **in current
module unit**. The difference here is that, if the declaration is used
in the imported modules, we used to emit it as an update. But we
definitely want to avoid that after this patch.

For that reproducer in
https://github.com/llvm/llvm-project/issues/61447, it used to take 2.5s
to compile and now it only takes 0.49s to compile, which is a big win.

show more ...

[Clang] Override method ModuleImportRead in MultiplexASTDeserializationListener

Fixes https://llvm.org/PR54521

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

[clang] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[AST] Add missing MultiplexConsumer::CompleteExternalDeclaration

[Clang] 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
o

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

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

llvm-svn: 368942

show more ...

[OPENMP 5.0]Add initial support for 'allocate' directive.

Added parsing/sema analysis/serialization/deserialization support for
'allocate' directive.

llvm-svn: 355614

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291

Make MultiplexASTDeserializationListener part of the API [NFC]

Summary:
This patch moves the MultiplexASTDeserializationListener declaration into a public header.

We're currently using this multipl

Make MultiplexASTDeserializationListener part of the API [NFC]

Summary:
This patch moves the MultiplexASTDeserializationListener declaration into a public header.

We're currently using this multiplexer in the cling interpreter to attach another
ASTDeserializationListener during the execution (so, after the MultiplexConsumer is already
attached which prevents us from attaching more). So far we're doing this by patching clang
and making this class public, but it makes things easier if we make this instead just public in
upstream.

Reviewers: thakis, v.g.vassilev, rsmith, bruno

Reviewed By: bruno

Subscribers: llvm-commits, cfe-commits, v.g.vassilev

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

llvm-svn: 331021

show more ...

Generalize "static data member instantiated" notification to cover variable templates too.

While here, split the "point of instantiation changed" notification out from
it; these two really are ortho

Generalize "static data member instantiated" notification to cover variable templates too.

While here, split the "point of instantiation changed" notification out from
it; these two really are orthogonal changes.

llvm-svn: 319727

show more ...

Support for destroying operator delete, per C++2a proposal P0722.

This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or significantly modified based on committ

Support for destroying operator delete, per C++2a proposal P0722.

This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or significantly modified based on committee feedback.

No functionality change intended for existing code (a new type must be defined
in namespace std to take advantage of this feature).

llvm-svn: 315662

show more ...

PR29097: add an update record when we instantiate the default member
initializer of an imported field.

llvm-svn: 279667

[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5

Support OpenMP version 4.5 syntax for #pragma omp declare target.

Syntax:
#pragma omp declare target (extended-list) new-li

[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5

Support OpenMP version 4.5 syntax for #pragma omp declare target.

Syntax:
#pragma omp declare target (extended-list) new-line
or
#pragma omp declare target clause[ [,] clause ... ] new-line

Where clause is one of the following:
to(extended-list)
link(list)

Differential Revision: http://reviews.llvm.org/D20011

llvm-svn: 268925

show more ...

[OPENMP] Parsing and Sema support for 'omp declare target' directive

Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0
(4.5 support will be added in separate patch).

The decl

[OPENMP] Parsing and Sema support for 'omp declare target' directive

Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0
(4.5 support will be added in separate patch).

The declare target directive specifies that variables, functions (C, C++
and Fortran), and subroutines (Fortran) are mapped to a device. The declare
target directive is a declarative directive. In Clang declare target is
implemented as implicit attribute for the declaration.

The syntax of the declare target directive is as follows:

#pragma omp declare target
declarations-definition-seq
#pragma omp end declare target

Based on patch from Michael Wong http://reviews.llvm.org/D15321

llvm-svn: 265530

show more ...

For MS ABI, emit dllexport friend functions defined inline in class

...as that is apparently what MSVC does. This is an updated version of r263738,
which had to be reverted in r263740 due to test f

For MS ABI, emit dllexport friend functions defined inline in class

...as that is apparently what MSVC does. This is an updated version of r263738,
which had to be reverted in r263740 due to test failures. The original version
had erroneously emitted functions that are defined in class templates, too (see
the updated "Handle friend functions" code in EmitDeferredDecls,
lib/CodeGen/ModuleBuilder.cpp). (The updated tests needed to be split out into
their own dllexport-ms-friend.cpp because of the CHECK-NOTs which would have
interfered with subsequent CHECK-DAGs in dllexport.cpp.)

Differential Revision: http://reviews.llvm.org/D18430

llvm-svn: 264841

show more ...

Revert "For MS ABI, emit dllexport friend functions defined inline in class"

This reverts commit r263738.

This appears to cause a failure in
CXX/temp/temp.decls/temp.friend/p1.cpp

llvm-svn: 263740

For MS ABI, emit dllexport friend functions defined inline in class

Summary: ...as that is apparently what MSVC does

Reviewers: rnk

Patch by Stephan Bergmann

Differential Revision: http://reviews

For MS ABI, emit dllexport friend functions defined inline in class

Summary: ...as that is apparently what MSVC does

Reviewers: rnk

Patch by Stephan Bergmann

Differential Revision: http://reviews.llvm.org/D15267

llvm-svn: 263738

show more ...