| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
#137363 was supposed to be NFC for the `CrossProcessModuleCache` (a.k.a
normal implicit module builds), but accidentally passed the wrong path
to `sys::fs::status`. Then, #141358 removed the correct path that
should've been passed instead. (The variable was flagged as unused.)
None of our existing tests caught this regression, we only found out due
to a SourceKit-LSP benchmark getting slower.
This PR re-implements the original behavior, adds new remark to Clang
for PCM input file validation, and uses it to create more reliable tests
of the `-fmodules-validate-once-per-build-session` flag.
|
|
With lazy template loading, it is possible to find non-canonical
FunctionDecls, depending on when redecl chains are completed. This
is a problem for templated conversion operators that would allow to
call either the copy assignment or the move assignment operator.
This ambiguity is resolved by isBetterReferenceBindingKind (called
from CompareStandardConversionSequences) ranking rvalue refs over
lvalue refs.
Unfortunately, this fix is hard to test in isolation without the
changes in https://github.com/llvm/llvm-project/pull/133057 that
make lazy template loading more likely to complete redecl chains
at "inconvenient" times. The added reproducer passes before and
after this commit, but would have failed with the proposed changes
of the linked PR.
Kudos to Maksim Ivanov for providing an initial version of the
reproducer that I further simplified.
|
|
(#161332)
Developers reported non-deterministic output from `-module-file-info`,
thinking this reflected non-determinism in the .pcm files themselves.
However, it turned out it was the printing that was non-deterministic:
```
$ cat /tmp/a.h
#define FOO 1
#define BAR 2
$ build/bin/clang -cc1 -std=c++20 -x c++ -emit-header-unit /tmp/a.h -o /tmp/a.pcm
$ build/bin/clang -cc1 -module-file-info /tmp/a.pcm | grep -A2 Definitions
Macro Definitions:
FOO
BAR
$ build/bin/clang -cc1 -module-file-info /tmp/a.pcm | grep -A2 Definitions
Macro Definitions:
BAR
FOO
```
Making the output deterministic also simplifies the test.
This is a follow-up to 360c5fe54c0758c73bf85453fd2913f371adc7d5
|
|
The debug info for VTables introduced in #130255 was temporarily
disabled on COFF platforms by #151684, due to the risk of emitting
dangling relocations (see also:
https://github.com/llvm/llvm-project/issues/149639#issuecomment-3114257062
).
This patch re-enables that debug info and adds a guard to prevent
emitting dangling relocations by checking whether the VTable definition
is actually emitted.
Resolves #149639
|
|
Otherwise test may fail on some systems.
Fixes tests after #159771
|
|
This PR refactor no-stable-modtime.m to use split-file
Signed-off-by: yicuixi <qin_17914@126.com>
|
|
(#159771)
Fixes #159768.
When building a named module interface with `-fmodules` enabled,
importing a Clang module from inside the global module fragment causes
Clang to crash only on assertion builds.
This fixes the assert and extends the test coverage.
|
|
Now that we have the %readfile substitution, we can rewrite these tests
that were using env variable subshells to write the output of the
command into a file and then load it where it is needed using readfile.
This does involve one invocation of bash so that we are using the system
env binary, which does support redirection into a tool like grep. We
already do this in one LLVM test. I'm not happy about needing that, but
the more principled way to solve it involves reworking how in-process
builtins work within lit. That is something we want to do eventually,
but not something that I think should block this patch.
Reviewers: cmtice, petrhosek, ilovepi
Reviewed By: cmtice, ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/158446
|
|
|
|
Close https://github.com/llvm/llvm-project/issues/159424
Close https://github.com/llvm/llvm-project/issues/133720
For in-class friend declaration, it is hard for the serializer to decide
if they are visible to other modules. But luckily, Sema can handle it
perfectly enough. So it is fine to make all of the in-class friend
declaration as generally visible in ASTWriter and let the Sema to make
the final call. This is safe as long as the corresponding class's
visibility are correct.
|
|
While working on vector deleting destructors support
([GH19772](https://github.com/llvm/llvm-project/issues/19772)), I
noticed that MSVC produces different code in scalar deleting destructor
body depending on whether class defined its own operator delete. In
MSABI deleting destructors accept an additional implicit flag parameter
allowing some sort of flexibility. The mismatch I noticed is that
whenever a global operator delete is called, i.e. `::delete`, in the
code produced by MSVC the implicit flag argument has a value that makes
the 3rd bit set, i.e. "5" for scalar deleting destructors "7" for vector
deleting destructors.
Prior to this patch, clang handled `::delete` via calling global
operator delete direct after the destructor call and not calling class
operator delete in scalar deleting destructor body by passing "0" as
implicit flag argument value. This is fine until there is an attempt to
link binaries compiled with clang with binaries compiled with MSVC. The
problem is that in binaries produced by MSVC the callsite of the
destructor won't call global operator delete because it is assumed that
the destructor will do that and a destructor body generated by clang
will never do.
This patch removes call to global operator delete from the callsite and
add additional check of the 3rd bit of the implicit parameter inside of
scalar deleting destructor body.
---------
Co-authored-by: Tom Honermann <tom@honermann.net>
|
|
GCC 14 also made this an error by default, so we’re following suit.
Fixes #74605
|
|
We just called `getInit()`, which isn't always correct and used the
wrong initializer in the module test case.
|
|
|
|
This test attempts to run a reproducer script generated by clang. This
is intended to be run by a shell, so invoke it with an actual shell.
This enables running the test with LLVM lit's internal shell.
Reviewers: bcardosolopes, ilovepi, petrhosek
Reviewed By: ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/157608
|
|
Most of these tests do not actually have a shell requirement. The shell
requirement ended up in the test either from cargo culting (from what I
can tell) or because the test authors actually meant to mark Windows as
unsupported. This prevents enablement of lit's internal shell within
clang.
Towards #102699.
Reviewers: rnk, efriedma-quic, Sirraide, petrhosek, ilovepi
Reviewed By: ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/156905
|
|
This reverts commit 613caa909c78f707e88960723c6a98364656a926, essentially
reapplying 4a4bddec3571d78c8073fa45b57bbabc8796d13d after moving
`normalizeModuleCachePath` from clangFrontend to clangLex.
This PR is part of an effort to remove file system usage from the
command line parsing code. The reason for that is that it's impossible
to do file system access correctly without a configured VFS, and the VFS
can only be configured after the command line is parsed. I don't want to
intertwine command line parsing and VFS configuration, so I decided to
perform the file system access after the command line is parsed and the
VFS is configured - ideally right before the file system entity is used
for the first time.
This patch delays normalization of the module cache path until
`CompilerInstance` is asked for the cache path in the current
compilation context.
|
|
This reverts commit 4a4bddec3571d78c8073fa45b57bbabc8796d13d. The Serialization library doesn't link Frontend, where CompilerInstance lives, causing link failures on some build bots.
|
|
This PR is part of an effort to remove file system usage from the
command line parsing code. The reason for that is that it's impossible
to do file system access correctly without a configured VFS, and the VFS
can only be configured after the command line is parsed. I don't want to
intertwine command line parsing and VFS configuration, so I decided to
perform the file system access after the command line is parsed and the
VFS is configured - ideally right before the file system entity is used
for the first time.
This patch delays normalization of the module cache path until
`CompilerInstance` is asked for the cache path in the current
compilation context.
|
|
different modules
See the attached example for motivation. Although it is not sure how
should we treat the modules ownership of the implicit instantiations,
it makes no sense to diagnose redeclaration of implicit instantiations
in different modules.
|
|
env -u is not suppoted on AIX. Disable these tests for now on that
platform until we can finish enabling the internal shell by default.
|
|
The root cause of the issue is that we forgot to update the abbrev
number correctly.
The test would crash before.
|
|
This fixes the workaround added in 8a63989, so that when a fake
definition data is corrected, all redeclarations are also updated to
point to it.
Since this regression was never released, there are no release notes.
Fixes #154840
|
|
These two tests started failing after being enabled again on Windows due
to the removal of their shell requirements now that they can execute
with lit's internal shell. However, they use forward slashes in file
paths in FileCheck assertions, which has been leading to failures on
certain bots.
https://lab.llvm.org/buildbot/#/builders/46/builds/22798
https://lab.llvm.org/buildbot/#/builders/193/builds/10297
|
|
This patch rewrites a couple tsts that fail when running with lit's
internal shell enabled due to assumptions about setting environment
variables. There were a couple cases where there was an implict env.
Most of the cases needed unset swapped for env -u.
Toeards #102699.
Reviewers: petrhosek, efriedma-quic, Sirraide, carlocab, rnk, ilovepi
Reviewed By: carlocab, rnk, ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/156904
|
|
|
|
Clang modules sort the umbrella dir headers by name before adding to the
module's includes to ensure deterministic output across different file
systems.
This is insufficient however, as the header search table is also
serialized.
This includes all the loaded headers by file reference, which are
allocated
incrementally. To ensure stable output we have to also create the file
references in sorted order.
|
|
Correct few typos: 'seperate' -> 'separate' .
|
|
|
|
|
|
The import and include problem is a long-standing issue with the use of
C++20 modules. This patch tried to improve this by skipping parsing
class and functions if their declaration is already defined in modules.
The scale of the patch itself is small as the patch reuses previous
optimization. Maybe we can skip parsing other declarations in the
future. But the patch itself should be good.
|
|
import first and include later
For the common pattern:
```C++
module;
export module a;
...
```
```C++
// a.cpp
import a;
```
In this case, we're already able to skip parsing the body of some
declarations in a.cpp. Add a test to show the ability.
|
|
In C++, it can be assumed the same linkage will be computed for all
redeclarations of an entity, and we have assertions to check this.
However, the linkage for a declaration can be requested in the middle of
deserealization, and at this point the redecl chain is not well formed,
as computation of the most recent declaration is deferred.
This patch makes that assertion work even in such conditions.
This fixes a regression introduced in
https://github.com/llvm/llvm-project/pull/147835, which was never
released, so there are no release notes for this.
Fixes #153933
|
|
Close https://github.com/llvm/llvm-project/issues/138558
The compiler failed to understand the redeclaration-relationship when
performing checks when MergeFunctionDecl. This seemed to be a complex
circular problem (how can we know the redeclaration relationship before
performing merging?). But the fix seems to be easy and safe. It is fine
to only perform the check only if the using decl is a local decl.
|
|
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes #136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
|
|
Several Clang tests were failing on Cygwin, and were already marked as
requiring !system-windows, unsupported on system-windows, or xfail on
system-windows. Add system-cygwin to lit's llvm.config, and use it in
such tests in addition to system-windows.
|
|
This fixes an ambiguous type type_info when you try and reference the
`type_info` type while using clang modulemaps with `-fms-compatibility`
enabled
Fixes #38400
|
|
(#151684)
On COFF platform, d1b0cbff806b50d399826e79b9a53e4726c21302 generates a
debug info linked with VTable regardless definition is present or not.
If that VTable ends up implicitly dllimported from another DLL, ld.bfd
produces a runtime pseudo relocation for it (LLD doesn't, since
d17db6066d2524856fab493dd894f8396e896bc7). If the debug section is
stripped, the runtime pseudo relocation points to memory space outside
of the module, causing an access violation.
At this moment, we simply disable VTable debug info on COFF platform to
avoid this problem.
|
|
This is still crashing on AIX and Solaris. It looks like maybe issues
due to trying to delete the current working directory. cd to the source
directory beforehand to try and work around that.
|
|
This reverts commit 4c80193a58a5c24e2bbebe291feb406191c4e2ab.
This relands the commit. The issues have theoretically been fixed.
|
|
Modules/specializations-lazy-load-parentmap-crash.cpp (#151259)
When the static analyzer is disabled with
-DCLANG_ENABLE_STATIC_ANALYZER=OFF, the newly added
specializations-lazy-load-parentmap-crash.cpp test fails with:
error: action RunAnalysis not compiled in
--
********************
********************
Failed Tests (1):
Clang :: Modules/specializations-lazy-load-parentmap-crash.cpp
Split out the part of the test that requires the static analyzer so that
it does not run when the static analyzer is unavailable.
|
|
This reverts commit 5a586375aa3a128dadc9473cfa196bf8588c2a82.
This breaks two buildbots with failures in
implicit-module-header-maps.cpp. No idea why these failures are
occurring.
https://lab.llvm.org/buildbot/#/builders/64/builds/5166
https://lab.llvm.org/buildbot/#/builders/13/builds/8725
|
|
This patch removes %T from clang lit tests. %T has been deprecated for
about seven years and is not reccomended as it is not unique to each
test, which can lead to races. This patch is intended to remove usage in
tree with the end goal of removing support for %T within lit.
|
|
## Problem
This is a regression that was observed in Clang 20 on modules code that
uses import std.
The lazy-loading mechanism for template specializations introduced in
#119333 can currently load additional nodes when called multiple times,
which breaks assumptions made by code that iterates over
specializations. This leads to iterator invalidation crashes in some
scenarios.
The core issue occurs when:
1. Code calls `spec_begin()` to get an iterator over template
specializations. This invokes `LoadLazySpecializations()`.
2. Code then calls `spec_end()` to get the end iterator.
3. During the `spec_end()` call, `LoadExternalSpecializations()` is
invoked again.
4. This can load additional specializations for certain cases,
invalidating the begin iterator returned in 1.
I was able to trigger the problem when constructing a ParentMapContext.
The regression test demonstrates two ways to trigger the construction of
the ParentMapContext on problematic code:
- The ArrayBoundV2 checker
- Unsigned overflow detection in sanitized builds
Unfortunately, simply dumping the ast (e.g. using `-ast-dump-all`)
doesn't trigger the crash because dumping requires completing the redecl
chain before iterating over the specializations.
## Solution
The fix ensures that the redeclaration chain is always completed
**before** loading external specializations by calling
`CompleteRedeclChain(D)` at the start of
`LoadExternalSpecializations()`. The idea is to ensure that all
`SpecLookups` are fully known and loaded before the call to
`LoadExternalSpecializationsImpl()`.
|
|
Tracked at https://github.com/llvm/llvm-project/issues/112294
This patch implements from [basic.link]p14 to [basic.link]p18 partially.
The explicitly missing parts are:
- Anything related to specializations.
- Decide if a pointer is associated with a TU-local value at compile
time.
- [basic.link]p15.1.2 to decide if a type is TU-local.
- Diagnose if TU-local functions from other TU are collected to the
overload set. See [basic.link]p19, the call to 'h(N::A{});' in
translation unit #2
There should be other implicitly missing parts as the wording uses
"names" briefly several times. But to implement this precisely, we have
to visit the whole AST, including Decls, Expression and Types, which may
be harder to implement and be more time-consuming for compilation time.
So I choose to implement the common parts.
It won't be too bad to miss some cases since we DIDN'T do any such
checks in the past 3 years. Any new check is an improvement. Given
modules have been basically available since clang15 without such checks,
it will be user unfriendly if we give a hard error now. And there are
a lot of cases which violating the rule actually just fine. So I decide
to emit it as warnings instead of hard errors.
|
|
As documented in 20.x, we'd like to keep reduced BMI off by default for
1~2 versions. And now we're in 22.x.
I rarely receive bug reports for reduced BMI. I am not sure about the
reason. Maybe not a lot of people are using it. Or it is really stable
enough.
And also, we've been enabling the reduced BMI internally for roughly half a
year.
So I think it's the time to move on. See the document changes for other
information.
|
|
Change the error message from "export declaration can only be used
within a module purview" to "export declaration can only be used within
a module interface" to be technically accurate.
The previous message was misleading because export declarations are
actually within a module purview when used in module implementation
units, but they are only allowed in module interface units.
This addresses the issue pointed out in GitHub issue #149008 where
Bigcheese noted that the diagnostic wording was incorrect.
Fixes #149008
|
|
EvaluateAsInitializer does not support evaluating values with dependent
types. This was previously guarded with a check for the initializer
expression, but it is possible for the VarDecl to have a dependent type
without the initializer having a dependent type, when the initializer is
a specialized template type and the VarDecl has the unspecialized type.
This adds a guard checking for dependence in the VarDecl type as well.
This fixes the issue raised by Google in
https://github.com/llvm/llvm-project/pull/145447
|
|
All deserialized VarDecl initializers are EvaluatedStmt, but not all
EvaluatedStmt initializers are from a PCH. Calling
`VarDecl::hasInitWithSideEffects` can trigger constant evaluation, but
it's hard to know ahead of time whether that will trigger
deserialization - even if the initializer is fully deserialized, it may
contain a call to a constructor whose body is not deserialized. By
caching the result of `VarDecl::hasInitWithSideEffects` and populating
that cache during deserialization we can guarantee that calling it won't
trigger deserialization regardless of the state of the initializer.
This also reduces memory usage by removing the `InitSideEffectVars` set
in `ASTReader`.
rdar://154717930
|
|
See the attached test for the motiviation.
Previously we dependent on the module ownership of the decl context to
perform module local lookup. But if the lookup is unqualified, we may
perform the lookup with canonical decl, which belongs to the incorrect
named module
|
