[C++20] [Module] Support reachable definition initially/partially

This patch introduces a new kind of ModuleOwnershipKind as
ReachableWhenImported. This intended the status for reachable described
a

[C++20] [Module] Support reachable definition initially/partially

This patch introduces a new kind of ModuleOwnershipKind as
ReachableWhenImported. This intended the status for reachable described
at: https://eel.is/c++draft/module.reach#3.

Note that this patch is not intended to support all semantics about
reachable semantics. For example, this patch didn't implement discarded
declarations in GMF. (https://eel.is/c++draft/module.global.frag#3).

This fixes: https://bugs.llvm.org/show_bug.cgi?id=52281 and
https://godbolt.org/z/81f3ocjfW.

Reviewed By: rsmith, iains

Differential Revision: https://reviews.llvm.org/D113545

show more ...

Revert "[C++20] [Modules] Implement Reachable initiallly"

This reverts commit a223ba0a697c1598b434cf2495c9cd9ec5640fc7.

The previous commit don't contain additional information, which is bad.

[C++20] [Modules] Implement Reachable initiallly

[clang] Pass the NamedDecl* instead of the DeclarationName into many diagnostics.

Background:
-----------
There are two related argument types which can be sent into a diagnostic to
display the name

[clang] Pass the NamedDecl* instead of the DeclarationName into many diagnostics.

Background:
-----------
There are two related argument types which can be sent into a diagnostic to
display the name of an entity: DeclarationName (ak_declarationname) or
NamedDecl* (ak_nameddecl) (there is also ak_identifierinfo for
IdentifierInfo*, but we are not concerned with it here).

A DeclarationName in a diagnostic will just be streamed to the output,
which will directly result in a call to DeclarationName::print.

A NamedDecl* in a diagnostic will also ultimately result in a call to
DeclarationName::print, but with two customisation points along the way:

The first customisation point is NamedDecl::getNameForDiagnostic which is
overloaded by FunctionDecl, ClassTemplateSpecializationDecl and
VarTemplateSpecializationDecl to print the template arguments, if any.

The second customisation point is NamedDecl::printName. By default it just
streams the stored DeclarationName into the output but it can be customised
to provide a user-friendly name for an entity. It is currently overloaded by
DecompositionDecl and MSGuidDecl.

What this patch does:
---------------------
For many diagnostics a DeclarationName is used instead of the NamedDecl*.
This bypasses the two customisation points mentioned above. This patches fix
this for diagnostics in Sema.cpp, SemaCast.cpp, SemaChecking.cpp, SemaDecl.cpp,
SemaDeclAttr.cpp, SemaDecl.cpp, SemaOverload.cpp and SemaStmt.cpp.

I have only modified diagnostics where I could construct a test-case which
demonstrates that the change is appropriate (either with this patch or the next
one).

Reviewed By: erichkeane, aaron.ballman

Differential Revision: https://reviews.llvm.org/D84656

show more ...

[c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whose
template name is not visible to unqualified lookup.

In order to support this without a severe degradation in our ability to
di

[c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whose
template name is not visible to unqualified lookup.

In order to support this without a severe degradation in our ability to
diagnose typos in template names, this change significantly restructures
the way we handle template-id-shaped syntax for which lookup of the
template name finds nothing.

Instead of eagerly diagnosing an undeclared template name, we now form a
placeholder template-name representing a name that is known to not find
any templates. When the parser sees such a name, it attempts to
disambiguate whether we have a less-than comparison or a template-id.
Any diagnostics or typo-correction for the name are delayed until its
point of use.

The upshot should be a small improvement of our diagostic quality
overall: we now take more syntactic context into account when trying to
resolve an undeclared identifier on the left hand side of a '<'. In
fact, this works well enough that the backwards-compatible portion (for
an undeclared identifier rather than a lookup that finds functions but
no function templates) is enabled in all language modes.

llvm-svn: 360308

show more ...

[modules] Simplify and generalize the existing rule for finding hidden
declarations in redeclaration lookup. A declaration is now visible to
lookup if:

* It is visible (not in a module, or in an im

[modules] Simplify and generalize the existing rule for finding hidden
declarations in redeclaration lookup. A declaration is now visible to
lookup if:

* It is visible (not in a module, or in an imported module), or
* We're doing redeclaration lookup and it's externally-visible, or
* We're doing typo correction and looking for unimported decls.

We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.

This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on). It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).

This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.

llvm-svn: 252960

show more ...

[modules] Simplify -cc1 interface for enabling implicit module maps.

We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't

[modules] Simplify -cc1 interface for enabling implicit module maps.

We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.

The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.

llvm-svn: 239789

show more ...

[modules] Better support for redefinitions of an entity from the same module.

Support this across module save/reload and extend the 'missing import'
diagnostics with a list of providing modules.

ll

[modules] Better support for redefinitions of an entity from the same module.

Support this across module save/reload and extend the 'missing import'
diagnostics with a list of providing modules.

llvm-svn: 239750

show more ...

Require a module.map file to load a module

Removes some old code that allowed a module to be loaded from a pcm file
even if the module.map could not be found. Also update a number of
tests that rel

Require a module.map file to load a module

Removes some old code that allowed a module to be loaded from a pcm file
even if the module.map could not be found. Also update a number of
tests that relied on the old behavior.

llvm-svn: 199852

show more ...

Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.

VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same so

Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.

VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.

This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:

// expected-error@file:line {{diagnostic message}}

This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.

The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.

This closes out PR15613.

llvm-svn: 179677

show more ...

Rename -fmodule-cache-path <blah> to -fmodules-cache-path=<blah> for consistency.

llvm-svn: 174645

Use @import rather than @__experimental_modules_import, since the
latter is rather a mess to type.

llvm-svn: 169919

When disambiguating an expression-statement from a declaraton-statement, if the
statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in

When disambiguating an expression-statement from a declaraton-statement, if the
statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in order to improve error recovery.

llvm-svn: 162464

show more ...

Change @import to @__experimental_modules_import. We are not ready to commit to a particular syntax for modules,
and don't have time to push it forward in the near future.

llvm-svn: 151841

Eliminate the uglified keyword __import_module__ for importing
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In

Eliminate the uglified keyword __import_module__ for importing
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In Objective-C/Objective-C++, the @import syntax is used to
import modules.

Note that, under -fmodules, C/C++ programs can import modules via the
#include mechanism when a module map is in place for that header. This
allows us to work with modules in C/C++ without committing to a syntax.

llvm-svn: 147467

show more ...

When performing name lookup for a redeclaration, ignore module
visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
t

When performing name lookup for a redeclaration, ignore module
visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.

As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.

Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.

llvm-svn: 146980

show more ...

Eliminate the -emit-module option, which emitted a module by parsing a
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.

llvm-svn:

Eliminate the -emit-module option, which emitted a module by parsing a
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.

llvm-svn: 145444

show more ...

Migrate a few more modules tests over to -emit-module-from-map.

llvm-svn: 144779

For modules, use a hash of the compiler version, language options, and
target triple to separate modules built under different
conditions. The hash is used to create a subdirectory in the module
cach

For modules, use a hash of the compiler version, language options, and
target triple to separate modules built under different
conditions. The hash is used to create a subdirectory in the module
cache path where other invocations of the compiler (with the same
version, language options, etc.) can find the precompiled modules.

llvm-svn: 139662

show more ...

Add a struct-size check for modules when dealing with module-private fields

llvm-svn: 139597

Introduce a cc1-level option to provide the path to the module cache,
where the compiler will look for module files. Eliminates the
egregious hack where we looked into the header search paths for
mod

Introduce a cc1-level option to provide the path to the module cache,
where the compiler will look for module files. Eliminates the
egregious hack where we looked into the header search paths for
modules.

llvm-svn: 139538

show more ...

Diagnose attempt to mark function-local declarations as __module_private__.

llvm-svn: 139519

Allow __module_private__ on fields

llvm-svn: 139499

Remove the restriction on module-private friends. Since the friend
declaration may be the first declaration, we want the ability to that
declaration to be marked module-private.

llvm-svn: 139497

Friends cannot be declared module-private

llvm-svn: 139411