| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hidden definition with a would-be-parsed redefinition.
This permits a bunch of cleanups. In particular, we no longer need to
take merged definitions into account when checking declaration
visibility, only when checking definition visibility, which makes
certain visibility checks take linear instead of quadratic time.
We could also now remove the UPD_DECL_EXPORTED update record and track
on each declaration whether it was demoted from a definition (as we
already do for variables), but I'm not doing that in this patch to keep
the changes here simpler.
llvm-svn: 342018
|
| |
|
|
|
|
|
|
| |
they're redeclarations. This is necessary in order for name lookup to correctly
find the most recent declaration of the name (which affects default template
argument lookup and cross-module merging, among other things).
llvm-svn: 275612
|
| |
|
|
|
|
|
| |
RequireCompleteType(..., 0) says we're not permitted to do so. The definition
might not be visible, even though we know what it is.
llvm-svn: 256045
|
| |
|
|
|
|
|
|
|
| |
the linkage of the enumeration. For enumerators of unnamed enumerations, extend
the -Wmodules-ambiguous-internal-linkage extension to allow selecting an
arbitrary enumerator (but only if they all have the same value, otherwise it's
ambiguous).
llvm-svn: 253010
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This failed to solve the problem it was aimed at, and introduced just as many
issues as it resolved. Realistically, we need to deal with the possibility that
multiple modules might define different internal linkage symbols with the same
name, and this isn't a problem unless two such symbols are simultaneously
visible.
The case where two modules define equivalent internal linkage symbols is
handled by r252063: if lookup finds multiple sufficiently-similar entities from
different modules, we just pick one of them as an extension (but we keep them
separate).
llvm-svn: 252957
|
| |
|
|
|
|
|
|
| |
context is the class itself but lookups should be performed starting with the
lookup parent of the class (class and base members don't shadow types from the
surrounding context because they have not been declared yet).
llvm-svn: 245236
|
| |
|
|
|
|
| |
the same anonymous union is defined across multiple modules.
llvm-svn: 243940
|
| |
|
|
|
|
| |
underlying types. A visible declaration is enough to make the type complete, but not enough to make the definition visible.
llvm-svn: 241743
|
| |
|
|
|
|
|
| |
rarely matters, but can affect whether two dependent types are canonically
equivalent.
llvm-svn: 241207
|
| |
|
|
|
|
|
| |
class template specialization visible just because the class template
specialization's definition is visible.
llvm-svn: 241182
|
| |
|
|
|
|
|
|
|
|
|
|
| |
redefinitions of internal-linkage symbols that are not visible.
Such conflicts are an accident waiting to happen, and this feature conflicts
with the desire to include existing headers into multiple modules and merge the
results. (In an ideal world, it should not be possible to export internal
linkage symbols from a module, but sadly the glibc and libstdc++ headers
provide 'static inline' functions in a few cases.)
llvm-svn: 240335
|
| |
|
|
|
|
| |
making either of them visible makes the merged definition visible.
llvm-svn: 239969
|
| |
|
|
| |
llvm-svn: 239954
|
| |
|
|
|
|
| |
that we know when its default arguments should be visible.
llvm-svn: 239936
|
| |
|
|
|
|
| |
argument is not visible.
llvm-svn: 239934
|
| |
|
|
|
|
|
|
|
| |
Previously we'd complain about redefinition of default arguments when we
instantiated a class with a friend template that inherits its default argument,
because we propagate the default template arguemnt onto the friend when we
reload the AST.
llvm-svn: 239857
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Support this across module save/reload and extend the 'missing import'
diagnostics with a list of providing modules.
llvm-svn: 239750
|
| |
|
|
| |
llvm-svn: 239578
|
| |
|
|
| |
llvm-svn: 239575
|
| |
|
|
|
|
| |
disabled but local module visibilty was enabled.
llvm-svn: 239504
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
llvm-svn: 237473
|
| |
|
|
|
|
| |
not visible definition of the same template.
llvm-svn: 233430
|
| |
|
|
|
|
|
|
| |
if the merged definition is visible, and perform lookups into all merged copies
of the definition (not just for special members) so that we can complete the
redecl chains for members of the class.
llvm-svn: 233420
|
| |
|
|
| |
llvm-svn: 233407
|
| |
|
|
|
|
| |
top of an existing imported-but-not-visible definition.
llvm-svn: 233345
|
| |
|
|
|
|
| |
imported-but-not-visible definition.
llvm-svn: 233341
|
|
|
non-visible definition, skip the new definition and make the old one visible
instead of trying to parse it again and failing horribly. C++'s ODR allows
us to assume that the two definitions are identical.
llvm-svn: 233250
|
