History log of /external/clang/test/Modules/Inputs/def.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
6bd992946bda92193fadce7e4890d4465d2702f4 09-Feb-2013 Douglas Gregor <dgregor@apple.com> Ensure that type definitions present in just-loaded modules are
visible.

The basic problem here is that a given translation unit can use
forward declarations to form pointers to a given type, say,

class X;
X *x;

and then import a module that includes a definition of X:

import XDef;

We will then fail when attempting to access a member of X, e.g.,

x->method()

because the AST reader did not know to look for a default of a class
named X within the new module.

This implementation is a bit of a C-centric hack, because the only
definitions that can have this property are enums, structs, unions,
Objective-C classes, and Objective-C protocols, and all of those are
either visible at the top-level or can't be defined later. Hence, we
can use the out-of-date-ness of the name and the identifier-update
mechanism to force the update.

In C++, we will not be so lucky, and will need a more advanced
solution, because the definitions could be in namespaces defined in
two different modules, e.g.,

// module 1
namespace N { struct X; }

// module 2
namespace N { struct X { /* ... */ }; }

One possible implementation here is for C++ to extend the information
associated with each identifier table to include the declaration IDs
of any definitions associated with that name, regardless of
context. We would have to eagerly load those definitions.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174794 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/def.h
303aae98a5a27f2595d023c0b4e1484bf2c0ee57 06-Jan-2012 Douglas Gregor <dgregor@apple.com> When inferring a submodule ID during module creation, look up the
include stack to find the first file that is known to be part of the
module. This copes with situations where the module map doesn't
completely specify all of the headers that are involved in the module,
which can come up when there are very strange #include_next chains
(e.g., with weird compiler/stdlib headers like stdarg.h or float.h).



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147662 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/def.h
d07cc36c71558b62889691184dd04655a33fd12a 02-Jan-2012 Douglas Gregor <dgregor@apple.com> Diagnose cases where the definition of a particular type is required,
is known (to Clang), but is not visible because the module has not yet
been imported.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147436 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/def.h
553689148f546783e127749438bf6d7806e6bb1d 14-Dec-2011 Douglas Gregor <dgregor@apple.com> When name lookup comes across a declaration that is in a module that
is not visible, look for any previous declarations of that entity that
might be visible.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146563 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/def.h