summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/linkage-merge.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [modules] In C++, stop serializing and deserializing a list of declarations inRichard Smith2015-07-211-4/+0
| | | | | | | | | the identifier table. This is redundant, since the TU-scope lookups are also serialized as part of the TU DeclContext, and wasteful in a number of ways. We still emit the decls for PCH / preamble builds, since for those we want identical results, not merely semantically equivalent ones. llvm-svn: 242855
* [modules] Simplify -cc1 interface for enabling implicit module maps.Richard Smith2015-06-161-1/+1
| | | | | | | | | | | | | 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
* [modules] Remove redundant import of lexical decls when building a lookup tableRichard Smith2015-03-231-3/+2
| | | | | | | | | | | | | | | 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
* Reverting 232853 and 232870 because they depend on 232793,Vince Harron2015-03-221-2/+3
| | | | | | which was reverted because it was causing LLDB test failures llvm-svn: 232907
* [modules] Remove temporary IdentifierInfo lookup results when we're done ↵Richard Smith2015-03-201-3/+2
| | | | | | with them. llvm-svn: 232853
* [modules] Rework merging of redeclaration chains on module import.Richard Smith2015-03-051-2/+7
| | | | | | | | | | | | | | | | | | | | | | We used to save out and eagerly load a (potentially huge) table of merged formerly-canonical declarations when we loaded each module. This was extremely inefficient in the presence of large amounts of merging, and didn't actually save any merging lookup work, because we still needed to perform name lookup to check that our merged declaration lists were complete. This also resulted in a loss of laziness -- even if we only needed an early declaration of an entity, we would eagerly pull in all declarations that had been merged into it regardless. We now store the relevant fragments of the table within the declarations themselves. In detail: * The first declaration of each entity within a module stores a list of first declarations from imported modules that are merged into it. * Loading that declaration pre-loads those other entities, so that they appear earlier within the redeclaration chain. * The name lookup tables list the most recent local lookup result, if there is one, or all directly-imported lookup results if not. llvm-svn: 231424
* DR101, PR12770: If a function is declared in the same context as aRichard Smith2014-02-061-3/+2
| | | | | | | | using-declaration, and they declare the same function (either because the using-declaration is in the same namespace as the declaration it imports, or because they're both extern "C"), they do not conflict. llvm-svn: 200897
* Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.Andy Gibbs2013-04-171-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add a module testcase with a using declaration.Rafael Espindola2013-04-051-2/+8
| | | | | | Thanks a lot to Richard Smith for the suggestion. llvm-svn: 178825
* Add hasExternalLinkageUncached back with the test that Richard provided, butRafael Espindola2013-04-041-0/+7
keep the call at the current location. llvm-svn: 178741
OpenPOWER on IntegriCloud