History log of /external/clang/test/Modules/diamond.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
651f13cea278ec967336033dd032faef0e9fc2ec 24-Apr-2014 Stephen Hines <srhines@google.com> Updated to Clang 3.5a.

Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/test/Modules/diamond.c
b42f200777a66b98989160bf3987ce431540a584 17-Apr-2013 Andy Gibbs <andyg1001@hotmail.co.uk> 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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179677 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
953a61f26bf79932b9699b09add4c388764de170 07-Feb-2013 Douglas Gregor <dgregor@apple.com> Rename -fmodule-cache-path <blah> to -fmodules-cache-path=<blah> for consistency.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174645 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
1b257afbae854c6817f26b7d61c4fed8ff7aebad 11-Dec-2012 Douglas Gregor <dgregor@apple.com> Use @import rather than @__experimental_modules_import, since the
latter is rather a mess to type.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169919 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
32ad2ee2618745ce3da51c2ae066ed5f21157c07 01-Mar-2012 Ted Kremenek <kremenek@apple.com> 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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151841 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
c13a34b690d2dc2a03c2fea75a0a1438636c19ce 03-Jan-2012 Douglas Gregor <dgregor@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147467 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
07165b9e3b78ed76a7db561f392335e4a54c9e51 02-Dec-2011 Douglas Gregor <dgregor@apple.com> When making a module visible, also make any of its exported modules
visible, allowing one to create modules that import (and then
re-export) other modules.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145696 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
ecc2c090e7146c029dd9ee9a5a2fd66b275c01c0 01-Dec-2011 Douglas Gregor <dgregor@apple.com> Implement name hiding for declarations deserialized from a non-visible
module. When that module becomes visible, so do those declarations.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145640 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
6649014b792f8a4b1bc1e8be8f844a72220af508 29-Nov-2011 Douglas Gregor <dgregor@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145444 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
db1cde7dc7bb3aaf48118bd9605192ab94a93635 16-Nov-2011 Douglas Gregor <dgregor@apple.com> Add support for building a module from a module map to the -cc1
interface. This is currently limited to modules with umbrella
headers.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144736 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
6e975c4517958bcc11c834336d340797356058db 14-Sep-2011 Douglas Gregor <dgregor@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139662 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
9a6da6930644b4f2dbe4885b0eb4fc1274ff56a4 12-Sep-2011 Douglas Gregor <dgregor@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139538 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
65030af6526748ce11534e92f0ccefc44091ba13 31-Aug-2011 Douglas Gregor <dgregor@apple.com> Switch __import__ over to __import_module__, so we don't conflict with
existing practice with Python extension modules. Not that Python
extension modules should be using a double-underscored identifier
anyway, but...


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138870 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
6aa52ec6b969faabf3764baf79d89810b8249a7e 27-Aug-2011 Douglas Gregor <dgregor@apple.com> Introduce support for a simple module import declaration, which
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138679 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
0c02adaa4da1d87495ca6a6d394f78740fa475c4 20-Aug-2011 Douglas Gregor <dgregor@apple.com> Make the loading of multiple records for the same identifier (from
different modules) more robust. It already handled (simple) merges of
the set of declarations attached to that identifier, so add a test
case that shows us getting two different declarations for the same
identifier (one struct, one function) from different modules, and are
able to use both of them.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138189 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
211f6e894895f552e0a98421b2f6e931ca4a8c11 20-Aug-2011 Douglas Gregor <dgregor@apple.com> Introduce a module visitation function that starts at the top-level
modules (those that no other module depends on) and performs a search
over all of the modules, visiting a new module only when all of the
modules that depend on it have already been visited. The visitor can
abort the search for all modules that a module depends on, which
allows us to minimize the number of lookups necessary when performing
a search.

Switch identifier lookup from a linear walk over the set of modules to
this module visitation operation. The behavior is the same for simple
PCH and chained PCH, but provides the proper search order for
modules. Verified with printf debugging, since we don't have enough in
place to actually test this.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138187 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
fac4ece118d43e43e625c6d2b9a98905b1372d51 19-Aug-2011 Douglas Gregor <dgregor@apple.com> Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.

This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.

Note that this version moves the file-opening logic into the module
manager, rather than splitting it between the module manager and the
AST reader. More importantly, it properly handles the
weird-but-possibly-useful case of loading an AST file from "-".


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138030 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
870d1fee3c5027efe7fd23d6935952bc1f419f99 18-Aug-2011 Chad Rosier <mcrosier@apple.com> Temporarily revert r137925 to appease buildbots. Original commit message:

Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.

This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137971 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c
a4c189f4356f24d984aac781d7762b8c55082b7e 18-Aug-2011 Douglas Gregor <dgregor@apple.com> Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.

This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.




git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137925 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/diamond.c