[AST] Incorrectly qualified unscoped enumeration as template actual parameter.

An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope,

[AST] Incorrectly qualified unscoped enumeration as template actual parameter.

An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope, as its visibility is
global.

In the case of scoped enumerations, they must include information
about their enclosing scope.

Patch by Carlos Alberto Enciso!

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

llvm-svn: 321312

show more ...

[modules] Don't emit initializers for VarDecls within a module eagerly whenever
we first touch any part of that module. Instead, defer them until the first
time that module is (transitively) imported

[modules] Don't emit initializers for VarDecls within a module eagerly whenever
we first touch any part of that module. Instead, defer them until the first
time that module is (transitively) imported. The initializer step for a module
then recursively initializes modules that its own headers imported.

For example, this avoids running the <iostream> global initializer in programs
that don't actually use iostreams, but do use other parts of the standard
library.

llvm-svn: 276159

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] Remove redundant import of lexical decls when building a lookup table
for a DeclContext, and fix propagation of exception specifications along
redeclaration chains.

This reverts r232905, r

[modules] Remove redundant import of lexical decls when building a lookup table
for a DeclContext, and fix propagation of exception specifications along
redeclaration chains.

This reverts r232905, r232907, and r232907, which reverted r232793, r232853,
and r232853.

One additional change is present here to resolve issues with LLDB: distinguish
between whether lexical decls missing from the lookup table are local or are
provided by the external AST source, and still look in the external source if
that's where they came from.

llvm-svn: 232928

show more ...

Reverting r232793 until some new LLDB failures are discussed

llvm-svn: 232905

[modules] Remove some redundant work when building a lookup table for a DeclContext.

When we need to build the lookup table for a DeclContext, we used to pull in
all lexical declarations for the con

[modules] Remove some redundant work when building a lookup table for a DeclContext.

When we need to build the lookup table for a DeclContext, we used to pull in
all lexical declarations for the context; instead, just build a lookup table
for the local lexical declarations. We previously didn't guarantee that the
imported declarations would be in the returned map, but in some cases we'd
happen to put them all in there regardless. Now we're even lazier about this.

This unnecessary work was papering over some other bugs:

- LookupVisibleDecls would use the DC for name lookups in the TU in C, and
this was not guaranteed to find all imported names (generally, the DC for
the TU in C is not a reliable place to perform lookups). We now use an
identifier-based lookup mechanism for this.

- We didn't actually load in the list of eagerly-deserialized declarations
when importing a module (so external definitions in a module wouldn't be
emitted by users of those modules unless they happened to be deserialized
by the user of the module).

llvm-svn: 232793

show more ...

[modules] Fix false report of an ODR violation when merging friend
declarations. We can't expect to find them in the canonical definition
of the class, because that's not where they live.

This means

[modules] Fix false report of an ODR violation when merging friend
declarations. We can't expect to find them in the canonical definition
of the class, because that's not where they live.

This means we no longer reject real ODR violations with friend declarations,
but we weren't consistently doing so anyway.

llvm-svn: 216369

show more ...

Basic ODR checking for C++ modules:

If we have multiple definitions of the same entity from different modules, we
nominate the first definition which we see as being the canonical definition.
If we

Basic ODR checking for C++ modules:

If we have multiple definitions of the same entity from different modules, we
nominate the first definition which we see as being the canonical definition.
If we load a declaration from a different definition and we can't find a
corresponding declaration in the canonical definition, issue a diagnostic.

This is insufficient to prevent things from going horribly wrong in all cases
-- we might be in the middle of emitting IR for a function when we trigger some
deserialization and discover that it refers to an incoherent piece of the AST,
by which point it's probably too late to bail out -- but we'll at least produce
a diagnostic.

llvm-svn: 192950

show more ...