When two modules contain interfaces with the same name, check the
definitions are equivalent and diagnose if they are not.
Differential Revision: https://reviews.llvm.org/D140073
mention developers to remember to touch the serializer after them
modified the field of decls
It is easy for the developers to forget to touch the serializer after
they add new field to decls. Then if the existing tests fail to catch
such cases, it may be a bug report from users some day. And it is
time-consuming to solve such bugs.
To mitigate the problem, I add the static_asserts in the serializer. So
that the developers can understand they need to modify the serializer
after they saw the static assertion failure. Although this can't solve
all the problems, I feel the current status can be much better.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D141992
This commit relands the patches for implementing P0960R3 and P1975R0,
which describe initializing aggregates via a parenthesized list.
The relanded commits are:
* 40c52159d3ee - P0960R3 and P1975R0: Allow initializing aggregates from
a parenthesized list of values
* c77a91bb7ba7 - Remove overly restrictive aggregate paren init logic
* 32d7aae04fdb - Fix a clang crash on invalid code in C++20 mode
This patch also fixes a crash in the original implementation.
Previously, if the input tried to call an implicitly deleted copy or
move constructor of a union, we would then try to initialize the union
by initializing it's first element with a reference to a union. This
behavior is incorrect (we should fail to initialize) and if the type of
the first element has a constructor with a single template typename
parameter, then Clang will explode. This patch fixes that issue by
checking that constructor overload resolution did not result in a
deleted function before attempting parenthesized aggregate
initialization.
Additionally, this patch also includes D140159, which contains some
minor fixes made in response to code review comments in the original
implementation that were made after that patch was submitted.
Co-authored-by: Sheng <ox59616e@gmail.com>
Fixes#54040, Fixes#59675
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D141546
This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/59675
Revert "[clang] Fix a clang crash on invalid code in C++20 mode."
This reverts commit 32d7aae04fdb58e65a952f281ff2f2c3f396d98f.
Revert "[clang] Remove overly restrictive aggregate paren init logic"
This reverts commit c77a91bb7ba793ec3a6a5da3743ed55056291658.
Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values"
This reverts commit 40c52159d3ee337dbed14e4c73b5616ea354c337.
This patch implements P0960R3, which allows initialization of aggregates
via parentheses.
As an example:
```
struct S { int i, j; };
S s1(1, 1);
int arr1[2](1, 2);
```
This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:
```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;
int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```
This patch was originally authored by @0x59616e and completed by
@ayzhao.
Fixes#54040, Fixes#54041
Co-authored-by: Sheng <ox59616e@gmail.com>
Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D129531
This patch gives basic parsing and semantic support for "modifiers" of order clause introduced in OpenMP 5.1 ( section 2.11.3 )
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D127855
Different versions of a lambda will in general refer to different
enclosing variable declarations, because we do not merge most
block-scope declarations, such as local variables. Keep track of all the
declarations that correspond to a lambda's capture fields so that we can
rewrite the name of any of those variables to the lambda capture,
regardless of which copy of the body of `operator()` we look at.
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 patch changes the PCM serialization logic to refer to input files by their "requested" name. This fixes a bug where the dependency scanner reports the "final" file paths, which can result in failed explicit compiles due to the `module.modulemap` file not being surrounded by the expected framework directory structure.
Depends on D135634.
Reviewed By: benlangmuir, Bigcheese
Differential Revision: https://reviews.llvm.org/D135636
With implicitly built modules, the importing `CompilerInstance` assumes PCMs were built in a "compatible way" (i.e. with similarly set up instance). Either because their context hash matches, or because this instance has just built them.
There are some use-cases, however, where this assumption doesn't hold, libclang/c-index-test being one of them. There, the importing instance (or `ASTUnit`) is being set up while the PCM file is being deserialized. Until now, we've assumed the serialized paths to input files are the actual on-disk files, meaning the default physical VFS was always able to resolve them. This won't be the case after D135636. Therefore, this patch makes sure `ASTUnit` is initialized with the same VFS as the PCM it's deserializing - by storing paths to the VFS overlay files into the PCM itself.
For the VFS overlay files to be adopted at the very start of PCM deserialization, they are stored in a new section in the unhashed control block, together with header search paths and system header prefixes. The move to the unhashed control block should be safe: if two modules were built with different header search paths and they produced different results, the hashed part of the PCM file will reflect that.
Reviewed By: akyrtzi, benlangmuir
Differential Revision: https://reviews.llvm.org/D135634
This reverts commit f0ce827c6972009c5052f8447c6aadf4e4be6113.
This reapplies commit 83973cf157f7850eb133a4bbfa0f8b7958bad215.
The new test now should pass on Windows thanks to commit 4d6483e91bb8f4147ff4001e6a11e373d5198e1c.
This reverts commit 67f34054d6ea8e40fd10cb74441d5ccab004c75b.
This reapplies commit f99e5a9106f08ad92a22c3b114d2052e5c502924.
This improves commit 8ab388e158528d9af5eb0376ef698b243d946f19 that unsucessfully attempted to forward-fix Windows test failure.
With this patch, we mark module maps that include an affecting `extern` module map as also affecting. This is a generalization of D137197: now we don't require the importing module map to describe parent of the extern module.
Depends on D137198.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D137206
Currently, the algorithm for gathering affecting module maps includes only those defining modules that include some headers. This is not entirely correct, though. Some module maps might be "importing" module maps for `extern` submodules. Such parent module maps are affecting - they do change semantics of the compilation. This patch adds parent module maps into the set of affecting module maps.
Depends on D137197.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D137198
Currently, the algorithm for gathering affecting module maps includes those defining transitive dependencies. This seems like an over-approximation, since those don't change the semantics of current module build.
(With this patch, `ModulesToProcess` only ever holds modules whose headers will be serialized into the current PCM.)
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D137197
When late parsed templates are used with PCH tokens are serialized. The
existing code does not handle annotation tokens which can occur due to
various pragmas.
This patch implements the serialization for annot_pragma_loop_hint.
This also enables use of OpenMP pragmas and #pragma unused which do not
need special serialization of the PtrData field.
Fixes https://github.com/llvm/llvm-project/issues/39504
Differential Revision: https://reviews.llvm.org/D138453
Extend SM_SLOC_BUFFER_BLOB_COMPRESSED to allow zstd, which is much faster
(compression/decompression) than zlib with a similar compression ratio.
An alternative is to add a value beside SM_SLOC_BUFFER_BLOB_COMPRESSED, but
reusing SM_SLOC_BUFFER_BLOB_COMPRESSED slightly simplifies the implementation
and leads to better diagnostics when a slightly older Clang consumes zstd
compressed blob.
Compressing AST takes a small portion of WriteAST, so we can pick a higher
compression level.
Compiling a relatively large .pcm (absl endian) with -fmodules-embed-all-files,
zstd level 9 has comparable performance with zlib-chromium level 6 (default),
but provides smaller output (5809156 => 5796016). Higher zstd levels will make
"Compress AST" notably slower and do not provide significant more size saving.
```
2.219345 Total ExecuteCompiler
0.746799 Total Frontend
0.736862 Total Source
0.339434 Total ReadAST
0.165452 Total WriteAST
0.043045 Total Compress AST
0.008236 Total ParseClass
0.00633 Total InstantiateClass
0.001887 Total isPotentialConstantExpr
0.001808 Total InstantiateFunction
0.001535 Total EvaluateForOverflow
0.000986 Total EvaluateAsRValue
0.000536 Total EvaluateAsBooleanCondition
0.000308 Total EvaluateAsConstantExpr
0.000156 Total EvaluateAsInt
3.4e-05 Total EvaluateKnownConstInt
8e-06 Total EvaluateAsInitializer
0 Total PerformPendingInstantiations
```
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D137885
This patch gives basic parsing and semantic analysis support for 'strict'
modifier with 'num_tasks' clause of 'taskloop' construct introduced in
OpenMP 5.1 (section 2.12.2)
Differential Revision: https://reviews.llvm.org/D138328
This patch gives basic parsing and semantic analysis support for 'strict'
modifier with 'grainsize' clause of 'taskloop' construct introduced in
OpenMP 5.1 (section 2.12.2)
Differential Revision: https://reviews.llvm.org/D138217
It is meaningless to emit macro definitions for named modules. With some
small experiments, the size of the module for the named modules reduced
2%~4% after this patch.
Error directive is allowed in both declared and executable contexts.
The function ActOnOpenMPAtClause is called in both places during the
parsers.
Adding a param "bool InExContext" to identify context which is used to
emit error massage.
Differential Revision: https://reviews.llvm.org/D137851
Use a FileEntryRef when retrieving modulemap paths in the scanner so
that we use a path compatible with the original module import, rather
than a FileEntry which can allow unrelated modules to leak paths into
how we build a module due to FileManager mutating the path.
Note: the current change prevents an "unrelated" path, but does not
change how VFS mapped paths are handled (which would be calling
getNameAsRequested) nor canonicalize the path.
Differential Revision: https://reviews.llvm.org/D137989
The dependency scanner relies on the module map filtering logic in `ASTWriter`. The algorithm currently considers all system module maps affecting, which is not only sub-optimal, but can also cause failures when building a module explicitly (see attached test case).
This patch applies the same filtering logic to system module maps.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D136007
In D106876, we stopped serializing module map files that didn't affect compilation of the current module.
However, since each `SourceLocation` is simply an offset into `SourceManager`'s global buffer of concatenated input files in, these need to be adjusted during serialization. Otherwise, they can incorrectly point after the buffer or into subsequent input file.
This patch starts adjusting `SourceLocation`s, `FileID`s and other `SourceManager` offsets in `ASTWriter`.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D136624
This patch delays some `ASTWriter` logic until after we've checked whether the source location entry we're serializing as an affecting file or not.
Depends on D137214.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D137216
This patch is a NFC prep for D136624, where we start adjusting offsets into `SourceManager`.
Depends on D137213.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D137214
For pragma diagnostic mappings, we always write/read `SourceLocation` with offset 0. This is equivalent to just writing a `FileID`, which is exactly what this patch starts doing.
Depends on D137211.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D137213
This patch adds new functions for writing/reading `FileID`s and uses them to replace some ad-hoc code.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D137211
Removes a bunch of obsolete methods in favor of a single one returning
an ArrayRef of TemplateArgument.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136602
Disable the assertion for getting a module ID for non-local,
non-imported module. According to the FIXME this can "easily happen" and
indeed, we're hitting this assertion regularly. Disable it until it can
be properly investigated.
rdar://99352728
Differential revision: https://reviews.llvm.org/D136290
Fills gaps in the time trace when precompiled headers are created/loaded.
Reviewed By: jansvoboda11
Differential Revision: https://reviews.llvm.org/D135657
This is a follow-up to D134224. The original patch added new `ExcludedHeader` enumerator to `ModuleMap::ModuleHeaderRole` and started associating headers with the modules they were excluded from. This was necessary to consider their module maps as "affecting" in certain situations and in turn serialize them into the PCM.
The association of the header and module needs to be handled when deserializing the PCM as well, though. This patch fixes a potential assertion failure and a regression. This essentially reverts parts of feb54b6ded123f8118fdc20620d3f657dfeab485.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D135381
Update SourceManager::ContentCache::OrigEntry to keep the original
FileEntryRef, and use that to enable ModuleMap::getModuleMapFile* to
return the original FileEntryRef. This change should be NFC for
most users of SourceManager::ContentCache, but it could affect behaviour
for users of getNameAsRequested such as in compileModuleImpl. I have not
found a way to detect that difference without additional functional
changes, other than incidental cases like changes from / to \ on
Windows so there is no new test.
Differential Revision: https://reviews.llvm.org/D135220
This implements WG14 N2927 and WG14 N2930, which together define the
feature for typeof and typeof_unqual, which get the type of their
argument as either fully qualified or fully unqualified. The argument
to either operator is either a type name or an expression. If given a
type name, the type information is pulled directly from the given name.
If given an expression, the type information is pulled from the
expression. Recursive use of these operators is allowed and has the
expected behavior (the innermost operator is resolved to a type, and
that's used to resolve the next layer of typeof specifier, until a
fully resolved type is determined.
Note, we already supported typeof in GNU mode as a non-conforming
extension and we are *not* exposing typeof_unqual as a non-conforming
extension in that mode, nor are we exposing typeof or typeof_unqual as
a nonconforming extension in other language modes. The GNU variant of
typeof supports a form where the parentheses are elided from the
operator when given an expression (e.g., typeof 0 i = 12;). When in C2x
mode, we do not support this extension.
Differential Revision: https://reviews.llvm.org/D134286
