Tunnels `Manger` object into the `ScanningAllProjectModules` so it can
be used to perform necessary command-line modifications (which also adds
`--resources` path previously added there explicitly). This allows using
the experimental C++ modules support with gcc.
This was discussed in the issue with @ChuanqiXu9 and @kadircet
Closes#112635
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.
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)).
Summary:
After https://reviews.llvm.org/D143436 response files stopped working
with CDB interpolation. It has happened because interpolation removes
all unknown flags and extra input files. Response file is treated as an
extra input because it is not a flag. Moreover inference needs full
command line for driver mode and file type detection so all response
files have to be expanded for correct inference.
This patch partially reverts D143436 and add additional response file
expansion in OverlayCDB for CDBs pushed via LSP.
Test Plan: check-clangd
Tasks: https://github.com/llvm/llvm-project/issues/69690
There is a discrepancy between how clangd processes CDB loaded from
JSON file on disk and pushed via LSP. Thus the same CDB pushed via
LSP protocol may not work as expected. Some difference between these two
paths is expected but we still need to insert driver mode and target from
binary name and expand response files.
Test Plan: check-clang-tools
Differential Revision: https://reviews.llvm.org/D143436
There is a discrepancy between how clangd processes CDB loaded from
JSON file on disk and pushed via LSP. Thus the same CDB pushed via
LSP protocol may not work as expected. Some difference between these two
paths is expected but we still need to insert driver mode and target from
binary name and expand response files.
Test Plan: check-clang-tools
Differential Revision: https://reviews.llvm.org/D143436
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
This gives CommandMangler access to other fields of
tooling::CompileCommand as well, e.g. Directory.
Differential Revision: https://reviews.llvm.org/D133756
With GCC <6 constructing a function_ref from a free function reference
leads to it referencing a temporary function pointer. If the lifetime of
that temporary is insufficient it can crash.
Fixes https://github.com/clangd/clangd/issues/800
This reverts commit 253b8145dedbe8d10792f44b4af7f52dbecd527f.
This doesn't actually fix anything - I should stop guessing.
See https://github.com/clangd/clangd/issues/800 for update
The original code appears to be OK per the spec, but we've had 3 reports of
crashes with certain unofficial builds of clangd that look a lot like old
compilers (GCC 5.4?) getting lifetime rules wrong.
Fixes https://github.com/clangd/clangd/issues/800
Differential Revision: https://reviews.llvm.org/D106654
This is on the critical path (it blocks getting the compile command for
the first file).
It's not trivially fast: it involves processing all filenames in the CDB
and doing some IO to look for shadowing CDBs.
And we may make this slower soon - making CDB configurable implies evaluating
the config for each listed to see which ones really are owned by the
broadcasted CDB.
Differential Revision: https://reviews.llvm.org/D94606
When querying the CDB, we stat the underlying file to check it hasn't changed.
We don't do this every time, but only if we didn't check within 5 seconds.
This behavior only exists for compile_commands.json and compile_flags.txt.
The CDB plugin system doesn't expose enough information to handle others.
Slight behavior change: we now only look for `build/compile_commands.json`
rather than trying every CDB strategy under `build` subdirectories.
Differential Revision: https://reviews.llvm.org/D92663
Boost in its infinite wisdom considers C: a parent of C:\, and we've
inherited that. This breaks the assumption that after canonicalizing a
path, the path parents are the directory's parents.
This is a step towards making compile_commands.json reloadable.
The idea is:
- in addition to rare CDB loads we're soon going to have somewhat-rare CDB
reloads and fairly-common stat() of files to validate the CDB
- so stop doing all our work under a big global lock, instead using it to
acquire per-directory structures with their own locks
- each directory can be refreshed from disk every N seconds, like filecache
- avoid locking these at all in the most common case: directory has no CDB
Differential Revision: https://reviews.llvm.org/D92381
Summary:
Clangd is returning current working directory for overriden commands.
This can cause inconsistencies between:
- header and the main files, as OverlayCDB only contains entries for the main
files it direct any queries for the headers to the base, creating a
discrepancy between the two.
- different clangd instances, as the results will be different depending on the
timing of execution of the query and override of the command. hence clangd
might see two different project infos for the same file between different
invocations.
- editors and the way user has invoked it, as current working directory of
clangd will depend on those, hence even when there's no underlying base CWD
might change depending on the editor, or the directory user has started the
editor in.
This patch gets rid of that discrepency by always directing queries to base or
returning llvm::None in absence of it.
For a sample bug see https://reviews.llvm.org/D83099#2154185.
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D83934
Summary:
This matches the conventional location of cmake build directories.
It also allows creating a `build` symlink, which seems more flexible than the
compile_commands.json symlinks.
Reviewers: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78629
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Summary:
This was originally committed in 88bccded8fa169481fa367debf5ec615640635a1,
and reverted in 93f77617abba512d2861e2fc50ce385883f587b6.
This version is now much more testable: the "detect toolchain properties" part
is still not tested but also not active in tests.
All the command manipulation based on the detected properties is
directly tested, and also not active in other tests.
Fixes https://github.com/clangd/clangd/issues/211
Fixes https://github.com/clangd/clangd/issues/178
Reviewers: kbobyrev, ilya-biryukov
Subscribers: mgorny, ormris, cfe-commits, usaxena95, kadircet, arphaman, jkorous, MaskRay
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71029
