The macro expansion takes 13s and generates an 1.5M obj file, table uses
2s and 680k .o file.
Sanitizers take multiple minutes to compile the old version, while
having negligible overhead on the new version.
No change in functionality.
This reverts commit cbcb3eef70def3509bdffd4fe1ebfb6422afeaa2.
Causing many clangd test breakages, similar to:
error: no matching constructor for initialization of 'llvm::SmallVector<clang::tooling::stdlib::Header>'
: llvm::SmallVector<clang::tooling::stdlib::Header>(
^
Currently, we handle it as a symbol without a header. In general, for
the include-cleaner case, the std::get comes with the type header, it is
safe to ignore it.
Differential Revision: https://reviews.llvm.org/D144484
Clangd maintains a symbol map from standard library, in order to prevent
unexpected header/symbol leaks from internal files. (e.g. files under
`bits/` for libstdc++) This symbol map was generated by a python script
that parses pages of offline cppreference archive. The script didn't
handle the case for `std::experimental::`, where most symbols are from
TS. It works well as symbols are directly laid out in the corresponding
header under `experimental` directory for most of time.
However, libstdc++'s implementation split symbols of TS FS into a few
header files located in `experimental/bits`. This would make the code
completion provide internal headers when we simply select the symbols.
There are slightly differences between TS FS and C++17 FS. Some
functions like `system_complete` was replaced by `absolute` and
relative-related operations were introduced later by another proposal.
Even so, all mainstream implementation are based on N4100, the final
filesystem TS draft that was published in 2014 and from which symbols
we've added are exported.
This fixes https://github.com/clangd/clangd/issues/1481
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D142836
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
As pointed out in https://reviews.llvm.org/D119130#3829816, this
introduces a clang AST dependency to the clangToolingInclusions, which is used
by clang-format.
Since rest of the inclusion tooling doesn't depend on clang ast, moving this
into a separate library.
Differential Revision: https://reviews.llvm.org/D135245
