Decl::isInAnotherModuleUnit
Refactor `Sema::isModuleUnitOfCurrentTU` to `Decl::isInAnotherModuleUnit`
to make code simpler a little bit. Note that although this patch
introduces a FIXME, this is an existing issue and this patch just tries
to describe it explicitly.
The original code uses getTopLevelModuleName to compare if the module
matches. This is an overkill. Since in one program there will only be at
most one module name. So it is good enough to compare the module
directly. So that we can save some string comparisons.
even if its initializer has side effects
Close https://github.com/llvm/llvm-project/issues/61892
The variables whose initializer has side effects will be emitted even if
it is not used. But it shouldn't be true after we introduced modules.
The variables in other modules shouldn't be emitted if it is not used
even if its initializer has size effects.
Also this patch rename `Decl::isInCurrentModuleUnit` to
`Decl::isInAnotherModuleUnit` to make it closer to the semantics.
Decl::isInCurrentModuleUnit
Refactor `Sema::isModuleUnitOfCurrentTU` to `Decl::isInCurrentModuleUnit`
to make code simpler a little bit. Note that although this patch
introduces a FIXME, this is an existing issue and this patch just tries
to describe it explicitly.
Close https://github.com/llvm/llvm-project/issues/62589.
Previously, for global module fragments, we will justify if it is
visible by the visibility of their top level parents. But this is an
overkill, it is problematic if we have a deduction guide in the global
module fragments. See the attached test for example. In this example, we
will mark the global module fragments as visible, but our old strategy
will miss the case surprisingly due to we will only search for the top
level modules.
Since we don't always need the vendor extension to be in riscv_vector.td,
so it's better to make it be in separated header.
Depends on D148223 and D148680
Differential Revision: https://reviews.llvm.org/D148308
Extend `#pragma clang __debug dump` to support not only single identifier, but an expression as well. This makes it possible to test ADL and overload resolution directly, without being creative to make them observable via diagnostics (e.g. when [[ http://eel.is/c++draft/over.match.best | over.match.best ]] is involved). This implementation has a known limitation of not supporting dependent expressions properly, but it's quite useful even without such support.
Differential Revision: https://reviews.llvm.org/D144115
Close https://github.com/llvm/llvm-project/issues/60405
See the discussion in the above link for the background.
What the patch does:
- Rename `Module::ModuleKind::GlobalModuleFragment` to
`Module::ModuleKind::ExplicitGlobalModuleFragment`.
- Add another module kind `ImplicitGlobalModuleFragment` to
`ModuleKind`.
- Create an implicit global module fragment for the language linkage
declarations inside a module purview.
- If the language linkage lives inside the scope of an export decl,
the created modules is marked as exported to outer modules.
- In fact, Sema will only create at most 2 implicit global module
fragments to avoid creating a lot of unnecessary modules in the edging
case.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D144367
Close https://github.com/llvm/llvm-project/issues/60775
Previously, we will mark all the declarations in the GMF as not visible
to other module units. But this is too strict and the users may meet
problems during the template instantiation like the above exampel shows.
The patch addresseds the problem.
Close https://github.com/llvm/llvm-project/issues/60488.
Previously, when we instantiate a template, the argument dependent
lookup is performed in the context of the instantiation, which implies that the
functions not visible in the context can't be found by the argument
dependent lookup.
But this is not true, according to [module.context]p3, the instantiation
context for the implicit instantiation of a template should contain the
context of the primary module interface if the template is defined in
the module interface unit.
Note that the fix didn't implemnet [module.context]p3 precisely, see the
comments for example.
Close https://github.com/llvm/llvm-project/issues/59601.
This is actually a workaround for the issue. See the comments and the
test for example. The proper fix should make the placement allocation
functions acceptable based on the context. But it is harder and more
complex on the one side. On the other side, such workaround won't be too
bad in practice since users rarely call the placement allocation
functions directly.
So personally I prefer to address such problems in the simpler way.
Reviewed By: royjacobson
Differential Revision: https://reviews.llvm.org/D141023
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
gnu17 and earlier modes automatically expose several POSIX C APIs, and
this was accidentally disabled for gnu2x in
7d644e1215b376ec5e915df9ea2eeb56e2d94626.
This restores the behavior for gnu2x mode (without changing the
behavior in C standards modes instead of GNU modes).
Fixes#56607
Makes CheckTemplateArgumentList and the template deduction functions
produce a sugared converted argument list in addition to the canonical one.
This is mostly NFC except that we hook this up to a few diagnostics in
SemaOverload.
The infrastructure here will be used in subsequent patches
where we perform a finalized sugared substitution for entities
which we do not unique per specializations on canonical arguments,
and later on will be used for template specialization resugaring.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133874
Makes CheckTemplateArgumentList and the template deduction functions
produce a sugared converted argument list in addition to the canonical one.
This is mostly NFC except that we hook this up to a few diagnostics in
SemaOverload.
The infrastructure here will be used in subsequent patches
where we perform a finalized sugared substitution for entities
which we do not unique per specializations on canonical arguments,
and later on will be used for template specialization resugaring.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133874
LookupSpecialMember might fail, so changes the cast to cast_or_null.
Inside Sema, skip a particular base, similar to other cases, rather than
asserting on dtor showing up.
Other option would be to mark classes with invalid destructors as invalid, but
that seems like a lot more invasive and we do lose lots of diagnostics that
currently work on classes with broken members.
Differential Revision: https://reviews.llvm.org/D135254
This is first part for support cbuffer/tbuffer.
The format for cbuffer/tbuffer is
BufferType [Name] [: register(b#)] { VariableDeclaration [: packoffset(c#.xyzw)]; ... };
More details at https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-constants
New keyword 'cbuffer' and 'tbuffer' are added.
New AST node HLSLBufferDecl is added.
Build AST for simple cbuffer/tbuffer without attribute support.
The special thing is variables declared inside cbuffer is exposed into global scope.
So isTransparentContext should return true for HLSLBuffer.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129883
This adds a check for exported inline functions, that there is a definition in
the definition domain (which, in practice, can only be the module purview but
before any PMF starts) since the PMF definition domain cannot contain exports.
This is:
[dcl.inline]/7
If an inline function or variable that is attached to a named module is declared in
a definition domain, it shall be defined in that domain.
The patch also amends diagnostic output by excluding the PMF sub-module from the
set considered as sources of missing decls. There is no point in telling the user
that the import of a PMF object is missing - since such objects are never reachable
to an importer. We still show the definition (as unreachable), to help point out
this.
Differential Revision: https://reviews.llvm.org/D128328
Leverage the method OpenCL uses that adds C intrinsics when the lookup
failed. There is no need to define C intrinsics in the header file any
more. It could help to avoid the large header file to speed up the
compilation of RVV source code. Besides that, only the C intrinsics used
by the users will be added into the declaration table.
This patch is based on https://reviews.llvm.org/D103228 and inspired by
OpenCL implementation.
### Experimental Results
#### TL;DR:
- Binary size of clang increase ~200k, which is +0.07% for debug build and +0.13% for release build.
- Single file compilation speed up ~33x for debug build and ~8.5x for release build
- Regression time reduce ~10% (`ninja check-all`, enable all targets)
#### Header size change
```
| size | LoC |
------------------------------
Before | 4,434,725 | 69,749 |
After | 6,140 | 162 |
```
#### Single File Compilation Time
Testcase:
```
#include <riscv_vector.h>
vint32m1_t test_vadd_vv_vfloat32m1_t(vint32m1_t op1, vint32m1_t op2, size_t vl) {
return vadd(op1, op2, vl);
}
```
##### Debug build:
Before:
```
real 0m19.352s
user 0m19.252s
sys 0m0.092s
```
After:
```
real 0m0.576s
user 0m0.552s
sys 0m0.024s
```
~33x speed up for debug build
##### Release build:
Before:
```
real 0m0.773s
user 0m0.741s
sys 0m0.032s
```
After:
```
real 0m0.092s
user 0m0.080s
sys 0m0.012s
```
~8.5x speed up for release build
#### Regression time
Note: the failed case is `tools/llvm-debuginfod-find/debuginfod.test` which is unrelated to this patch.
##### Debug build
Before:
```
Testing Time: 1358.38s
Skipped : 11
Unsupported : 446
Passed : 75767
Expectedly Failed: 190
Failed : 1
```
After
```
Testing Time: 1220.29s
Skipped : 11
Unsupported : 446
Passed : 75767
Expectedly Failed: 190
Failed : 1
```
##### Release build
Before:
```
Testing Time: 381.98s
Skipped : 12
Unsupported : 1407
Passed : 74765
Expectedly Failed: 176
Failed : 1
```
After:
```
Testing Time: 346.25s
Skipped : 12
Unsupported : 1407
Passed : 74765
Expectedly Failed: 176
Failed : 1
```
#### Binary size of clang
##### Debug build
Before
```
text data bss dec hex filename
335261851 12726004 552812 348540667 14c64efb bin/clang
```
After
```
text data bss dec hex filename
335442803 12798708 552940 348794451 14ca2e53 bin/clang
```
+253K, +0.07% code size
##### Release build
Before
```
text data bss dec hex filename
144123975 8374648 483140 152981763 91e5103 bin/clang
```
After
```
text data bss dec hex filename
144255762 8447296 483268 153186326 9217016 bin/clang
```
+204K, +0.13%
Authored-by: Kito Cheng <kito.cheng@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Reviewed By: khchen, aaron.ballman
Differential Revision: https://reviews.llvm.org/D111617
This includes the revised provisions of [basic.lookup.argdep] p4
1. ADL is amended to handle p 4.3 where functions in trasitively imported modules may
become visible when they are exported in the same namespace as a visible type.
2. If a function is in a different modular TU, and has internal-linkage, we invalidate
its entry in an overload set.
[basic.lookup.argdep] p5 ex 2 now passes.
Differential Revision: https://reviews.llvm.org/D129174
Currently, clang may meet an infinite loop in a very tricky case when it
iterates the default args. This patch tries to fix this by adding a
`fixed` check.
Previously, we forget to handle reachability for deduction guide.
The deduction guide is a hint to the compiler. And the deduction guide
should be able to use if the corresponding template decl is reachable.
Now the implementation would accept following code:
```
//--- impl.cppm
module M:impl;
class A {};
//--- M.cppm
export module M;
import :impl;
//--- Use.cpp
import M;
void test() {
A a; // Expected error. A is not visible here.
}
```
which is clearly wrong. The root cause is the implementation of
`isInCurrentModule` would return true if the module is a partition! So
in the above example, although Use.cpp is not a module unit,
`isInCurrentModule ` would still return true when the compiler tries to
see if the owning module of `A` is the current module. I believe this is
an oversight. This patch tries to fix this problem.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D123837
C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.
C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.
C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.
This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.
Differential Revision: https://reviews.llvm.org/D122983
Motivation: The intent here is for use in Swift.
When building a clang module for swift consumption, swift adds an
extension block to the module for name lookup purposes. Swift calls
this a SwiftLookupTable. One purpose that this serves is to handle
conflicting names between ObjC classes and ObjC protocols. They exist in
different namespaces in ObjC programs, but in Swift they would exist in
the same namespace. Swift handles this by appending a suffix to a
protocol name if it shares a name with a class. For example, if you have
an ObjC class named "Foo" and a protocol with the same name, the
protocol would be renamed to "FooProtocol" when imported into swift.
When constructing the previously mentioned SwiftLookupTable, we use
Sema::LookupName to look up name conflicts for the previous problem.
By this time, the Parser has long finished its job so the call to
LookupName gets nullptr for its Scope (TUScope will be nullptr
by this point). The C/ObjC path does not have this problem because it
only uses the Scope in specific scenarios. The C++ codepath uses the
Scope quite extensively and will fail early on if the Scope it gets is
null. In our very specific case of looking up ObjC classes with a
specific name, we want to force sema::LookupName to take the C/ObjC
codepath even if C++ or ObjC++ is enabled.
Implementation partitions bring two extra cases where we have
visibility of module-private data.
1) When we import a module implementation partition.
2) When a partition implementation imports the primary module intertace.
We maintain a record of direct imports into the current module since
partition decls from direct imports (but not trasitive ones) are visible.
The rules on decl-reachability are much more relaxed (with the standard
giving permission for an implementation to load dependent modules and for
the decls there to be reachable, but not visible).
Differential Revision: https://reviews.llvm.org/D118599
This implements the parsing and recognition of module partition CMIs
and removes the FIXMEs in the parser.
Module partitions are recognised in the base computation of visibility,
however additional amendments to visibility follow in subsequent patches.
Differential Revision: https://reviews.llvm.org/D118586
This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
Update UnresolvedSet to use (and expose) `SmallVector::truncate()` instead
of `SmallVector::set_size()`. The latter is going to made private in a
future commit to avoid misuse.
Differential Revision: https://reviews.llvm.org/D115386
