summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/namespaces.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [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
* Render anonymous entities as '(anonymous <thing>)' (and lambdas as '(lambda ↵David Blaikie2014-04-021-2/+2
| | | | | | | | | | | | at ... )') For namespaces, this is consistent with mangling and GCC's debug info behavior. For structs, GCC uses <anonymous struct> but we prefer consistency between all anonymous entities but don't want to confuse them with template arguments, etc, so we'll just go with parens in all cases. llvm-svn: 205398
* Save out a correct lookup table if a lookup table entry is stale (it containsRichard Smith2014-03-251-0/+3
| | | | | | | | | an out-of-date external decls list). This happens if we declare some names, force the lookup table for the decl context to be built, import a module that adds more decls for the name, then write out our module without looking up the name. llvm-svn: 204694
* Consistently print anonymous namespace names as "<anonymous namespace>"David Blaikie2014-02-141-2/+2
| | | | | | | | | | | For some reason we have two bits of code handling this printing: lib/AST/Decl.cpp: OS << "<anonymous namespace>"; lib/AST/TypePrinter.cpp: OS << "<anonymous namespace>::"; it would be nice if we only had one... llvm-svn: 201437
* C++ modules: fix a bug where loading a declaration with some name would preventRichard Smith2013-09-091-0/+7
| | | | | | | | | | | | | | | | | name lookup from lazily deserializing the other declarations with the same name, by tracking a bit to indicate whether a name in a DeclContext might have additional external results. This also allows lazier reconciling of the lookup table if a module import adds decls to a pre-existing DC. However, this exposes a pre-existing bug, which causes a regression in test/Modules/decldef.mm: if we have a reference to a declaration, and a later-imported module adds a redeclaration, nothing causes us to load that redeclaration when we use or emit the reference (which can manifest as a reference to an undefined inline function, a use of an incomplete type, and so on). decldef.mm has been extended with an additional testcase which fails with or without this change. llvm-svn: 190293
* Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.Andy Gibbs2013-04-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rename -fmodule-cache-path <blah> to -fmodules-cache-path=<blah> for ↵Douglas Gregor2013-02-071-1/+1
| | | | | | consistency. llvm-svn: 174645
* Fix handling of module imports adding names to a DeclContext after qualifiedRichard Smith2013-02-071-6/+19
| | | | | | | | | | | | | | | | name lookup has been performed in that context (this probably only happens in C++). 1) Whenever we add names to a context, set a flag on it, and if we perform lookup and discover that the context has had a lookup table built but has the flag set, update all entries in the lookup table with additional names from the external source. 2) When marking a DeclContext as having external visible decls, mark the context in which lookup is performed, not the one we are adding. These won't be the same if we're adding another copy of a pre-existing namespace. llvm-svn: 174577
* Use @import rather than @__experimental_modules_import, since theDouglas Gregor2012-12-111-2/+2
| | | | | | latter is rather a mess to type. llvm-svn: 169919
* Fix PR10447: lazily building name lookup tables for DeclContexts was broken.Richard Smith2012-03-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | The deferred lookup table building step couldn't accurately tell which Decls should be included in the lookup table, and consequently built different tables in some cases. Fix this by removing lazy building of DeclContext name lookup tables. In practice, the laziness was frequently not worthwhile in C++, because we performed lookup into most DeclContexts. In C, it had a bit more value, since there is no qualified lookup. In the place of lazy lookup table building, we simply don't build lookup tables for function DeclContexts at all. Such name lookup tables are not useful, since they don't capture the scoping information required to correctly perform name lookup in a function scope. The resulting performance delta is within the noise on my testing, but appears to be a very slight win for C++ and a very slight loss for C. The C performance can probably be recovered (if it is a measurable problem) by avoiding building the lookup table for the translation unit. llvm-svn: 152608
* Change @import to @__experimental_modules_import. We are not ready to ↵Ted Kremenek2012-03-011-2/+2
| | | | | | | | commit to a particular syntax for modules, and don't have time to push it forward in the near future. llvm-svn: 151841
* When deserializing an anonymous namespace from a module, do not attachDouglas Gregor2012-01-091-0/+11
| | | | | | | | the anonymous namespace to its parent. Semantically, this means that the anonymous namespaces defined in one module are distinct from the anonymous namespaces defined in another module. llvm-svn: 147782
* Implement merging of namespace-scope declarations across modules, soDouglas Gregor2012-01-091-0/+13
| | | | | | | | | | that we can merge, for example, two occurrences of namespace N { void f(); } in two disjoint modules. llvm-svn: 147780
* Implement redeclaration merging for namespaces defined in distinctDouglas Gregor2012-01-091-0/+21
| | | | | | | | | modules. Teach name lookup into namespaces to search in each of the merged DeclContexts as well as the (now-primary) DeclContext. This supports the common case where two different modules put something into the same namespace. llvm-svn: 147778
* Switch NamespaceDecl from its own hand-rolled redeclaration chain overDouglas Gregor2012-01-071-0/+15
to Redeclarable<NamespaceDecl>, so that we benefit from the improveed redeclaration deserialization and merging logic provided by Redeclarable<T>. Otherwise, no functionality change. As a drive-by fix, collapse the "inline" bit into the low bit of the original namespace/anonymous namespace, saving 8 bytes per NamespaceDecl on x86_64. llvm-svn: 147729
OpenPOWER on IntegriCloud