[clangd] support outgoing calls in call hierarchy (#117673)

This reverts commit ce0f11325e0c62c5b81391589e9b93b412a85bc1.

Revert "[clangd] Re-land "support outgoing calls in call hierarchy" (#117673)"

This reverts commit 7be3326200ef382705d8e6b2d7dc5378af96b34a.

Per https://protobuf.dev/programming-guides/dos-donts/#a

Revert "[clangd] Re-land "support outgoing calls in call hierarchy" (#117673)"

This reverts commit 7be3326200ef382705d8e6b2d7dc5378af96b34a.

Per https://protobuf.dev/programming-guides/dos-donts/#add-required
this will re-land tomorrow without the required fields.

show more ...

[clangd] Re-land "support outgoing calls in call hierarchy" (#117673)

Co-authored-by: Quentin Chateau <quentin.chateau@gmail.com>

Revert "[clangd] Support outgoing calls in call hierarchy (#77556)" (#117668)

This reverts commit ca184cfc088a843e545e5f04b48813e6f9bfba77.

[clangd] Support outgoing calls in call hierarchy (#77556)

Co-authored-by: Quentin Chateau <quentin.chateau@gmail.com>

[clangd] Fix the modification detection logic in `ClangdLSPServer::applyConfiguration`. (#115438)

Prior to this, the "old != new" check would always evaluate to true because it was comparing a pre-m

[clangd] Fix the modification detection logic in `ClangdLSPServer::applyConfiguration`. (#115438)

Prior to this, the "old != new" check would always evaluate to true because it was comparing a pre-mangling new command to a post-mangling old command.

show more ...

[clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (#66462)

Alternatives to https://reviews.llvm.org/D153114.

Try to address https://github.com/clangd/clangd/issues/1293.

S

[clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (#66462)

Alternatives to https://reviews.llvm.org/D153114.

Try to address https://github.com/clangd/clangd/issues/1293.

See the links for design ideas and the consensus so far. We want to have
some initial support in clang18.

This is the initial support for C++20 Modules in clangd.
As suggested by sammccall in https://reviews.llvm.org/D153114,
we should minimize the scope of the initial patch to make it easier
to review and understand so that every one are in the same page:

> Don't attempt any cross-file or cross-version coordination: i.e. don't
> try to reuse BMIs between different files, don't try to reuse BMIs
> between (preamble) reparses of the same file, don't try to persist the
> module graph. Instead, when building a preamble, synchronously scan
> for the module graph, build the required PCMs on the single preamble
> thread with filenames private to that preamble, and then proceed to
> build the preamble.

This patch reflects the above opinions.

# Testing in real-world project

I tested this with a modularized library:
https://github.com/alibaba/async_simple/tree/CXX20Modules. This library
has 3 modules (async_simple, std and asio) and 65 module units. (Note
that a module consists of multiple module units). Both `std` module and
`asio` module have 100k+ lines of code (maybe more, I didn't count). And
async_simple itself has 8k lines of code. This is the scale of the
project.

The result shows that it works pretty well, ..., well, except I need to
wait roughly 10s after opening/editing any file. And this falls in our
expectations. We know it is hard to make it perfect in the first move.

# What this patch does in detail

- Introduced an option `--experimental-modules-support` for the support
for C++20 Modules. So that no matter how bad this is, it wouldn't affect
current users. Following off the page, we'll assume the option is
enabled.
- Introduced two classes `ModuleFilesInfo` and
`ModuleDependencyScanner`. Now `ModuleDependencyScanner` is only used by
`ModuleFilesInfo`.
- The class `ModuleFilesInfo` records the built module files for
specific single source file. The module files can only be built by the
static member function `ModuleFilesInfo::buildModuleFilesInfoFor(PathRef
File, ...)`.
- The class `PreambleData` adds a new member variable with type
`ModuleFilesInfo`. This refers to the needed module files for the
current file. It means the module files info is part of the preamble,
which is suggested in the first patch too.
- In `isPreambleCompatible()`, we add a call to
`ModuleFilesInfo::CanReuse()` to check if the built module files are
still up to date.
- When we build the AST for a source file, we will load the built module
files from ModuleFilesInfo.

# What we need to do next

Let's split the TODOs into clang part and clangd part to make things
more clear.

The TODOs in the clangd part include:
1. Enable reusing module files across source files. The may require us
to bring a ModulesManager like thing which need to handle `scheduling`,
`the possibility of BMI version conflicts` and `various events that can
invalidate the module graph`.
2. Get a more efficient method to get the `<module-name> ->
<module-unit-source>` map. Currently we always scan the whole project
during `ModuleFilesInfo::buildModuleFilesInfoFor(PathRef File, ...)`.
This is clearly inefficient even if the scanning process is pretty fast.
I think the potential solutions include:
- Make a global scanner to monitor the state of every source file like I
did in the first patch. The pain point is that we need to take care of
the data races.
- Ask the build systems to provide the map just like we ask them to
provide the compilation database.
3. Persist the module files. So that we can reuse module files across
clangd invocations or even across clangd instances.

TODOs in the clang part include:
1. Clang should offer an option/mode to skip writing/reading the bodies
of the functions. Or even if we can requrie the parser to skip parsing
the function bodies.

And it looks like we can say the support for C++20 Modules is initially
workable after we made (1) and (2) (or even without (2)).

show more ...

[clangd] Support go-to-definition on type hints. The protocol part (#85497)

This is in preparation for implementing go-to-definition support on type
inlay hints, switching the `label` field within

[clangd] Support go-to-definition on type hints. The protocol part (#85497)

This is in preparation for implementing go-to-definition support on type
inlay hints, switching the `label` field within the InlayHint protocol from a
string to an array of `InlayHintLabelPart`.

show more ...

[clangd] forward clang-tidy's readability-identifier-naming fix to textDocument/rename (#78454)

Co-authored-by: Nathan Ridge <zeratul976@hotmail.com>

Add support for renaming objc methods, even those with multiple selector pieces (#76466)

This adds support for renaming Objective-C methods, which are unique since their method names can be split a

Add support for renaming objc methods, even those with multiple selector pieces (#76466)

This adds support for renaming Objective-C methods, which are unique since their method names can be split across multiple tokens.

show more ...

[clangd] Prefer definitions for gototype and implementation

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

[clangd] Refine the workflow for diagnostic Fixits.

- No longer store the diagnostic fixits in the clangdLSPServer
- When propagating the fixit via the code action, we use the Diag
information sto

[clangd] Refine the workflow for diagnostic Fixits.

- No longer store the diagnostic fixits in the clangdLSPServer
- When propagating the fixit via the code action, we use the Diag
information stored in the ParsedAST (in clangdServer.cpp)

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

show more ...

[clangd] Fix some typos, NFC

[clangd] Always allow diagnostics from stale preambles

We've been running this internally for months now, without any
stability or correctness concerns. It has ~40% speed up on incremental
diagnosti

[clangd] Always allow diagnostics from stale preambles

We've been running this internally for months now, without any
stability or correctness concerns. It has ~40% speed up on incremental
diagnostics latencies (as preamble can get invalidated through code completion
etc.).

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

show more ...

[clangd] Move completion signatures and labelDetails

(When clients support it, otherwise keep the existing rendering).

In VSCode this makes the signature darker.

Differential Revision: https://rev

[clangd] Move completion signatures and labelDetails

(When clients support it, otherwise keep the existing rendering).

In VSCode this makes the signature darker.

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

show more ...

[clangd] Add batch fixes for include-cleaner diagnostics

For each unused-include/missing-include diagnostic, we provide fix-all
alternative to them.

This patch also adds LSP ChangeAnnotation suppor

[clangd] Add batch fixes for include-cleaner diagnostics

For each unused-include/missing-include diagnostic, we provide fix-all
alternative to them.

This patch also adds LSP ChangeAnnotation support.

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

show more ...

[clangd] Add support TextDocumentEdit.

This is an initial patch to add TextDocumentEdit (versioned edits) support in
clangd, the scope is minimal:

- add and extend the corresponding protocol struct

[clangd] Add support TextDocumentEdit.

This is an initial patch to add TextDocumentEdit (versioned edits) support in
clangd, the scope is minimal:

- add and extend the corresponding protocol structures
- propagate the documentChanges for diagnostic codeactions (our motivated case)

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

show more ...

[clangd] Inactive regions support via dedicated protocol

This implements the server side of the approach discussed at
https://github.com/clangd/vscode-clangd/pull/193#issuecomment-1044315732

Differ

[clangd] Inactive regions support via dedicated protocol

This implements the server side of the approach discussed at
https://github.com/clangd/vscode-clangd/pull/193#issuecomment-1044315732

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

show more ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Re

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

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

show more ...

[clang-tools-extra] Remove remaining uses of llvm::Optional (NFC)

This patch removes the unused "using" declaration and removes #include
"llvm/ADT/Optional.h".

This is part of an effort to migrate

[clang-tools-extra] Remove remaining uses of llvm::Optional (NFC)

This patch removes the unused "using" declaration and removes #include
"llvm/ADT/Optional.h".

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

[clang-tools-extra] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #i

[clang-tools-extra] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

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

[clang-tools-extra] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace

[clang-tools-extra] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
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

show more ...

[clangd] Add extension for adding context (enclosing function or class) in references results

Relevant issue: https://github.com/clangd/clangd/issues/177

Reviewed By: nridge

Differential Revision:

[clangd] Add extension for adding context (enclosing function or class) in references results

Relevant issue: https://github.com/clangd/clangd/issues/177

Reviewed By: nridge

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

show more ...

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_E

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).

This fixes check-clang-tools.

show more ...

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

Many files are from language servers.

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