summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
* Allow string literals as module names.Daniel Jasper2013-12-069-3/+41
| | | | | | | | | | | | | | | | | | In order to make the migration to modules easier, it seems to be helpful to allow a 1:1 mapping between target names of a current build system and the corresponding C++ modules. As such targets commonly contain characters like "-". ":" and "/", allowing arbitrary quote-escaped strings seems to be a straightforward option. After several offline discussions, the precise mechanisms for C++ module names especially regarding submodules and import statements has yet to be determined. Thus, this patch only enables string literals as names inside the module map files which can be used by automatic module import (through #include). Also improve the error message on missing use-declarations. llvm-svn: 196573
* Fix corner case in module-based layering warning.Daniel Jasper2013-12-031-1/+2
| | | | | | | | | | | Before, there SourceManager would not return a FileEntry for a SourceLocation of a macro expansion (if the header name itself is defined in a macro). We'd then fallback to assume that the module currently being built is the including module. However, in this case we are actually interested in the spelling location of the filename loc in order to derive the including module. llvm-svn: 196311
* Fix module name collision in tests.Richard Smith2013-11-232-6/+6
| | | | llvm-svn: 195545
* Generate a marker token when entering or leaving a submodule when building aRichard Smith2013-11-237-3/+40
| | | | | | | | | module. Use the marker to diagnose cases where we try to transition between submodules when not at the top level (most likely because a closing brace was missing at the end of a header file, but is also possible if submodule headers attempt to do something fundamentally non-modular, like our .def files). llvm-svn: 195543
* When we hit a #include directive that maps to a module import, emit a tokenRichard Smith2013-11-151-0/+4
| | | | | | | | | | | | representing the module import rather than making the module immediately visible. This serves two goals: * It avoids making declarations in the module visible prematurely, if we walk past the #include during a tentative parse, for instance, and * It gives a diagnostic (although, admittedly, not a very nice one) if a header with a corresponding module is included anywhere other than at the top level. llvm-svn: 194782
* Modules: Teach the preprocessor to recognize 'import' only after an '@'.Douglas Gregor2013-11-071-0/+9
| | | | | | | | | | | | The preprocessor currently recognizes module declarations to load a module based on seeing the 'import' keyword followed by an identifier. This sequence is fairly unlikely in C (one would need a type named 'import'), but is more common in Objective-C (where a variable named 'import' can cause problems). Since import declarations currently require a leading '@', recognize that in the preprocessor as well. Fixes <rdar://problem/15084587>. llvm-svn: 194225
* Include non-explicit submodules in exported module listDmitri Gribenko2013-11-046-0/+42
| | | | | | | | | | | | | | | | This change fixes Richard's testcase for r193815. Now we include non-explicit submodules into the list of exports. The test failed previously because: - recursive_visibility_a1.inner is not imported (only recursive_visibility_a1 is), - thus the 'inner' submodule is not showing up in any of the import lists, - and because of this getExportedModules() is not returning the correct module set -- it only considers modules that are imported. The fix is to make Module::getExportedModules() include non-explicit submodules into the list of exports. llvm-svn: 194018
* Allow a new syntax in a module requires-declaration:Richard Smith2013-10-285-1/+18
| | | | | | | | | | | | requires ! feature The purpose of this is to allow (for instance) the module map for /usr/include to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are instead provided by the C++ standard library in this case, and the glibc C <tgmath.h> header would otherwise try to include <complex.h>, resulting in a module cycle). llvm-svn: 193549
* Use the same SourceManager for ModuleMaps and compilations.Manuel Klimek2013-10-246-23/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows using virtual file mappings on the original SourceManager to map in virtual module.map files. Without this patch, the ModuleMap search will find a module.map file (as the FileEntry exists in the FileManager), but will be unable to get the content from the SourceManager (as ModuleMap previously created its own SourceManager). Two problems needed to be fixed which this patch exposed: 1. Storing the inferred module map When writing out a module, the ASTWriter stores the names of the files in the main source manager; when loading the AST again, the ASTReader errs out if such a file is found missing, unless it is overridden. Previously CompilerInstance's compileModule method would store the inferred module map to a temporary file; the problem with this approach is that now that the module map is handled by the main source manager, the ASTWriter stores the name of the temporary module map as source to the compilation; later, when the module is loaded, the temporary file has already been deleted, which leads to a compilation error. This patch changes the inferred module map to instead inject a virtual file into the source manager. This both saves some disk IO, and works with how the ASTWriter/ASTReader handle overridden source files. 2. Changing test input in test/Modules/Inputs/* Now that the module map file is handled by the main source manager, the VerifyDiagnosticConsumer will not ignore diagnostics created while parsing the module map file. The module test test/Modules/renamed.m uses -I test/Modules/Inputs and triggers recursive loading of all module maps in test/Modules/Inputs, some of which had conflicting names, thus leading errors while parsing the module maps. Those diagnostics already occur on trunk, but before this patch they would not break the test, as they were ignored by the VerifyDiagnosticConsumer. This patch thus changes the module maps that have been recently introduced which broke the invariant of compatible modules maps in test/Modules/Inputs. llvm-svn: 193314
* Make UsingShadowDecls redeclarable. This fixes some visibility problems withRichard Smith2013-10-234-0/+34
| | | | | | | | | | modules. With this fixed, I no longer see any test regressions in the libc++ test suite when enabling a single-module module.map for libc++ (other than issues with my system headers). llvm-svn: 193219
* Allow a header to be part of multiple modules.Daniel Jasper2013-10-2212-1/+54
| | | | | | | | | | | | | | | | | | | | This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
* Fix crash if a submodule @imports another submodule from the same module. TheRichard Smith2013-10-186-0/+27
| | | | | | | test also adds FIXMEs for a number of places where imports and includes of submodules don't work very well. llvm-svn: 193005
* C++ modules: don't lose track of a 'namespace std' that is imported from a ↵Richard Smith2013-10-183-0/+20
| | | | | | module. llvm-svn: 192951
* Basic ODR checking for C++ modules:Richard Smith2013-10-184-0/+48
| | | | | | | | | | | | | | | 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
* Test that we can merge together explicit and partial specializations fromRichard Smith2013-10-155-0/+35
| | | | | | merged declarations of a class template. llvm-svn: 192746
* C++ modules: merging for enumerations and enumerators with multiple definitionsRichard Smith2013-10-154-0/+34
| | | | | | (eg through template instantiations in multiple modules). llvm-svn: 192740
* Merge common pointers for redeclarations of the same template across modules.Richard Smith2013-10-133-0/+8
| | | | llvm-svn: 192560
* When merging class definitions across modules in C++, merge together fields.Richard Smith2013-10-074-2/+42
| | | | | | | | | This change doesn't go all the way to making fields redeclarable; instead, it makes them 'mergeable', which means we can find the canonical declaration, but not much else (and for a declaration that's not from a module, the canonical declaration is always that declaration). llvm-svn: 192092
* Add -fmodule-map-file option.Daniel Jasper2013-09-242-1/+1
| | | | | | | | | | | | | | | With this option, arbitrarily named module map files can be specified to be loaded as required for headers in the respective (sub)directories. This, together with the extern module declaration allows for specifying module maps in a modular fashion without the need for files called "module.map". Among other things, this allows a directory to contain two modules that are completely independent of one another. Review: http://llvm-reviews.chandlerc.com/D1697. llvm-svn: 191284
* Module use declarations (II)Daniel Jasper2013-09-2413-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
* Support for modular module-map-filesDaniel Jasper2013-09-115-0/+23
| | | | | | | | | | | | | | | | | | | This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
* C++ modules: if a class is defined in multiple modules (for instance, becauseRichard Smith2013-09-097-0/+33
| | | | | | | | | | | | it is an implicit instantiation of a class template specialization), pick the first-loaded definition to be the canonical definition, and merge all other definitions into it. This is still rather incomplete -- we need to extend every form of declaration that can appear within a CXXRecordDecl to be redeclarable if it came from an AST file (this includes fields, enumerators, ...). llvm-svn: 190315
* C++ modules: fix a bug where loading a declaration with some name would preventRichard Smith2013-09-095-5/+27
| | | | | | | | | | | | | | | | | 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
* Note when a decl is used in AST files.Eli Friedman2013-09-053-1/+11
| | | | | | | | | | | | | | | When an AST file is built based on another AST file, it can use a decl from the fist file, and therefore mark the "isUsed" bit. We need to note this in the AST file so that the bit is set correctly when the second AST file is loaded. This patch introduces the distinction between setIsUsed() and markUsed() so that we don't call into the ASTMutationListener callback when it wouldn't be appropriate. Fixes PR16635. llvm-svn: 190016
* Map from local decl IDs to global decl IDs when lazily deserializing friend ↵Richard Smith2013-08-304-0/+21
| | | | | | decl chains. llvm-svn: 189629
* During typo correction, check for an exact match in an unimported module. If weRichard Smith2013-08-206-20/+44
| | | | | | find one, then report the error as a missing import instead of as a typo. llvm-svn: 188821
* Fix FileCheck --check-prefix lines.Tim Northover2013-08-121-2/+2
| | | | | | | | | | Various tests had sprung up over the years which had --check-prefix=ABC on the RUN line, but "CHECK-ABC:" later on. This happened to work before, but was strictly incorrect. FileCheck is getting stricter soon though. Patch by Ron Ofir. llvm-svn: 188174
* When merging redeclaration chains across modules, if a declaration is visibleRichard Smith2013-08-023-0/+12
| | | | | | | | | | | | | | | | | | | in one module but is only declared as a friend in another module, keep it visible in the result of the merge. This is incomplete on two axes: 1) Our handling of local extern declarations is basically broken (we put them in the wrong decl context, and don't find them in redeclaration lookup, unless they've previously been declared), and this results in them making friends visible after a merge. 2) Eventually we'll need to mark that this has happened, and more carefully check whether a declaration should be visible if it was only visible in some of the modules in which it was declared. Fortunately it's rare for the identifier namespace of a declaration to change along its redeclaration chain. llvm-svn: 187639
* Fix assert when instantiating a default argument of a template defined in aRichard Smith2013-08-012-0/+5
| | | | | | module. llvm-svn: 187556
* When we perform dependent name lookup during template instantiation, it's notRichard Smith2013-07-256-5/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sufficient to only consider names visible at the point of instantiation, because that may not include names that were visible when the template was defined. More generally, if the instantiation backtrace goes through a module M, then every declaration visible within M should be available to the instantiation. Any of those declarations might be part of the interface that M intended to export to a template that it instantiates. The fix here has two parts: 1) If we find a non-visible declaration during name lookup during template instantiation, check whether the declaration was visible from the defining module of all entities on the active template instantiation stack. The defining module is not the owning module in all cases: we look at the module in which a template was defined, not the module in which it was first instantiated. 2) Perform pending instantiations at the end of a module, not at the end of the translation unit. This is general goodness, since it significantly cuts down the amount of redundant work that is performed in every TU importing a module, and also implicitly adds the module containing the point of instantiation to the set of modules checked for declarations in a lookup within a template instantiation. There's a known issue here with template instantiations performed while building a module, if additional imports are added later on. I'll fix that in a subsequent commit. llvm-svn: 187167
* If an unimported submodule of an imported module contains a declaration of aRichard Smith2013-07-144-0/+22
| | | | | | | global allocation or deallocation function, that should not cause that global allocation or deallocation function to become unavailable. llvm-svn: 186270
* Add 'not' to commands that are expected to fail.Rafael Espindola2013-07-047-10/+10
| | | | | | | This is at least good documentation, but also opens the possibility of using pipefail. llvm-svn: 185652
* Fix deserializing of class template partial specializations. Assign sequenceRichard Smith2013-06-255-12/+36
| | | | | | | | | | numbers as we deserialize class template partial specializations. We can't assume that the old sequence numbers will work. The sequence numbers are still deterministic, but are now a lot less predictable for class template partial specializations in modules/PCH. llvm-svn: 184811
* Check for matching template-parameter-lists when merging template declarations.Richard Smith2013-06-243-0/+34
| | | | llvm-svn: 184791
* Avoid adding entries to the DeclContext lookup table multiple times when lazilyRichard Smith2013-06-241-4/+0
| | | | | | | | | | | | | | | | | constructing a lookup table. Previously, buildLookup would add lookup table entries for each item lexically within the DC, and adding the first entry with a given name would trigger the external source to add all its entries with that name. Then buildLookup would carry on and re-add those entries all over again. Instead, follow a simple rule: a declaration from an external source is only ever made visible by the external source. One exception to this: since we don't usually build a lookup table for the TU in C, and we never serialize one, we don't expect the external source to provide lookups in the TU in C, so we build those ones ourselves. llvm-svn: 184696
* Slightly improve cross-module merging for function templates.Richard Smith2013-06-244-0/+61
| | | | llvm-svn: 184689
* [Modules] If a module map resides in a system header directory, treat it as ↵Douglas Gregor2013-06-213-0/+13
| | | | | | | | | a system module. This prevents -pedantic from causing warnings in the system headers used to create modules. Fixes <rdar://problem/14201171>. llvm-svn: 184560
* Add test header missing from r184504.Douglas Gregor2013-06-211-0/+3
| | | | llvm-svn: 184505
* When building a module, keep *all* declared methods in the global method pool.Douglas Gregor2013-06-213-0/+9
| | | | | | | | | | | | | | | | | As an optimization, we only kept declared methods with distinct signatures in the global method pool, to keep the method lists small. Under modules, however, one could have two different methods with the same signature that occur in different (sub)modules. If only the later submodule is important, message sends to 'id' with that selector would fail because the first method (the only one that got into the method pool) was hidden. When building a module, keep *all* of the declared methods. I did a quick check of both module build time and uses of modules, and found no performance regression despite this causing us to keep more methods in the global method pool. Fixes <rdar://problem/14148896>. llvm-svn: 184504
* Test files for private header patch.Lawrence Crowl2013-06-2015-0/+127
| | | | llvm-svn: 184472
* Suffixing #pragma comment(lib) library names with .lib if necessary. This ↵Aaron Ballman2013-05-241-1/+1
| | | | | | matches MSVC behavior, as well as allows us to properly link libraries such as the ones provided by the MSDN examples. llvm-svn: 182647
* User correct case for 'FileCheck'.Argyrios Kyrtzidis2013-05-241-1/+1
| | | | llvm-svn: 182632
* [modules] If we hit a failure while loading a PCH/module, abort parsing ↵Argyrios Kyrtzidis2013-05-241-0/+26
| | | | | | | | | | instead of trying to continue in an invalid state. Also don't let libclang create a PCH with such an error. Fixes rdar://13953768 llvm-svn: 182629
* Add arm_neon.h to the builtin intrinsics module map.Douglas Gregor2013-05-201-0/+6
| | | | | | Fixes <rdar://problem/13933913>. llvm-svn: 182268
* Fix broken testDouglas Gregor2013-05-201-1/+1
| | | | llvm-svn: 182264
* Add -Wincomplete-module, which detects when a header is included from a ↵Douglas Gregor2013-05-204-0/+12
| | | | | | module but isn't itself part of a module. llvm-svn: 182263
* clang/test/Modules/self-import-header/test.m: Add explicit -target.NAKAMURA Takumi2013-05-161-0/+1
| | | | | | | | Clang has an issue between mingw/include/float.h and clang/Headers/float.h with cyclic include_next. For now, it should work to suppress #include_next in clang/float.h with an explicit target. (It may work with -U__MINGW32__, though.) llvm-svn: 181988
* improve of note message and minor refactoring of my lastFariborz Jahanian2013-05-151-1/+1
| | | | | | patch (r181847). llvm-svn: 181896
* Objective-C [diagnostics] [QOI], when method is notFariborz Jahanian2013-05-141-0/+1
| | | | | | | | found for a receiver, note where receiver class is declaraed (this is most common when receiver is a forward class). // rdar://3258331 llvm-svn: 181847
* [modules] When building a module, make sure we don't serialize out ↵Argyrios Kyrtzidis2013-05-086-0/+22
| | | | | | | | | | | HeaderFileInfo for headers not belonging to the module. After r180934 we may initiate module map parsing for modules not related to the module what we are building, make sure we ignore the header file info of headers from such modules. First part of rdar://13840148 llvm-svn: 181489
OpenPOWER on IntegriCloud