summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/Inputs
Commit message (Collapse)AuthorAgeFilesLines
...
* Add missing file from r204570.Richard Smith2014-03-231-0/+5
| | | | llvm-svn: 204574
* If a name is injected into an imported inline namespace without reopening thatRichard Smith2014-03-232-0/+10
| | | | | | | namespace, we need to update both the visible names of that namespace and of its enclosing namespace set. llvm-svn: 204570
* When we inject a declaration into a namespace, add the primary DeclContext toRichard Smith2014-03-232-0/+7
| | | | | | | the update set rather than the current DeclContext. Add test for the local extern case too. llvm-svn: 204568
* If a template instantation introduces a name into a namespace, we need to writeRichard Smith2014-03-232-0/+8
| | | | | | | out a visible update record for that namespace even if it was never declared in this module. llvm-svn: 204554
* If an update record makes a declaration interesting, pass it to the consumer.Richard Smith2014-03-232-0/+8
| | | | llvm-svn: 204550
* Emit an update record if we instantiate the definition of a function templateRichard Smith2014-03-223-0/+12
| | | | | | | | specialization from a module. (This can also happen for function template specializations in PCHs if they're instantiated eagerly, because they're constexpr or have a deduced return type.) llvm-svn: 204547
* Refactor: move loading pending instantiations from chained PCHs to a more ↵Richard Smith2014-03-221-0/+3
| | | | | | appropriate place, so that we only ask the external source once. llvm-svn: 204535
* PR19215: When writing/reading a PCH that imported a module, store the locationRichard Smith2014-03-213-0/+6
| | | | | | | at which that PCH imported each visible submodule of the module. Such locations are needed when synthesizing macro directives resulting from the import. llvm-svn: 204417
* Add a new spelling for module map files 'module.modulemap'Ben Langmuir2014-03-1916-0/+27
| | | | | | | | | | | | | | | This name, while more verbose, plays more nicely with tools that use file extensions to determine file types. The existing spelling 'module.map' will continue to work, but the new spelling will take precedence. In frameworks, this new filename will only go in a new 'Modules' sub-directory. Similarly, add a module.private.modulemap corresponding to module_private.map. llvm-svn: 204261
* Use the expansion location of the file name when finding the module.Manuel Klimek2014-03-192-0/+19
| | | | | | | | The spelling location of stringified strings is not a file location. Optimally, we'll want to solve the problem (as the FIXME states) by handing in the right FileEntry of the #include location. llvm-svn: 204220
* Don't verify module inclusions in assembler files.Daniel Jasper2014-03-142-0/+4
| | | | llvm-svn: 203929
* If a visibility update record is found for a DeclContext after that Decl hasRichard Smith2014-03-114-0/+4
| | | | | | | already been loaded, apply that update record to the Decl immediately, rather than adding it to a pending list and never applying it. llvm-svn: 203534
* If a module map is found in a relative -I path, convert the filenames within itRichard Smith2014-03-112-0/+2
| | | | | | | | to absolute paths when building the includes file for the module. Without this, the module build would fail, because the relative paths we were using are not necessarily relative to a directory in our include path. llvm-svn: 203528
* When a type's definition is instantiated, the definition becomes visible, evenRichard Smith2014-03-106-0/+39
| | | | | | | | | if the type's declaration was previously instantiated in an unimported module. (For an imported type definition, this already worked, because the source location is set to the location of the definition, but for locally-instantiated type definitions, it did not.) llvm-svn: 203425
* Module [extern_c] attribute: inherit to submodules, don't write 'extern "C"'Richard Smith2014-03-083-1/+3
| | | | | | blocks when building in C mode, and serialize and deserialize the attribute. llvm-svn: 203317
* Fix crash if a submodule overrides one of its own macros, and add support forRichard Smith2014-03-064-0/+11
| | | | | | | | submodule macro overriding within the same top-level module (necessary for the testcase to be remotely reasonable). Incidentally reduces the number of libc++ testsuite regressions with modules enabled from 7 to 6. llvm-svn: 203063
* If a #include finds a file relative to the current file, don't forget to checkRichard Smith2014-03-053-0/+8
| | | | | | whether it's part of a module. llvm-svn: 203005
* Fix typo that resulted in names at TU scope getting lost sometimes after aRichard Smith2014-03-041-0/+8
| | | | | | module import. llvm-svn: 202771
* Add [extern_c] attribute for modules, allowing a C module to be imported ↵Richard Smith2014-03-024-0/+9
| | | | | | within an extern "C" block in C++ code. llvm-svn: 202615
* If a module A exports a macro M, and a module B imports that macro and #undef'sRichard Smith2014-03-015-1/+18
| | | | | | | | | | | | | | it, importers of B should not see the macro. This is complicated by the fact that A's macro could also be visible through a different path. The rules (as hashed out on cfe-commits) are included as a documentation update in this change. With this, the number of regressions in libc++'s testsuite when modules are enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are due to remaining bugs in this change (in particular, the handling of submodules is imperfect). llvm-svn: 202560
* Fix comment typo in test.Richard Smith2014-01-311-1/+3
| | | | llvm-svn: 200584
* Fix autolinking when modules are imported in pch filesBen Langmuir2014-01-313-0/+7
| | | | | | | | | | | | Add the ImportDecl to the set of interesting delcarations that are deserialized eagerly when an AST file is loaded (rather than lazily like most decls). This is required to get auto linking to work when there is no explicit import in the main file. Also resolve a FIXME to rename 'ExternalDefinitions', since that is only one of the things that need eager deserialization. The new name is 'EagerlyDeserializedDecls'. The corresponding AST bitcode is also renamed. llvm-svn: 200505
* Enable layering check in unavailable modules.Daniel Jasper2013-12-201-0/+2
| | | | | | | | | | | | | | | If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
* Add missing file from r197485.Daniel Jasper2013-12-171-0/+2
| | | | | | (Yes, the irony is not lost on me :-) ). llvm-svn: 197486
* Modules: Don't warn upon missing headers while reading the module map.Daniel Jasper2013-12-172-1/+6
| | | | | | | | | | | | | | | Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. This works towards the long-term goal of not stat'ing the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this unblock us and moves us into the right direction. Also changed the implementation to reuse the same DiagnosticsEngine. llvm-svn: 197485
* Revert "Modules: Make missing headers in a module.map a warning not an error."Daniel Jasper2013-12-162-2/+0
| | | | | | This was committed accidentally. llvm-svn: 197389
* Modules: Make missing headers in a module.map a warning not an error.Daniel Jasper2013-12-162-0/+2
| | | | | | | | | | | | | | | | Instead, mark the module as unavailable so that clang errors as soon as someone tries to build this module. A better long-term strategy might be to not stat the header files at all while reading the module map and instead read them only when the module is being built (there is a corresponding FIXME in parseHeaderDecl()). However, it seems non-trivial to get there and this would be a temporary solution to unblock us. Also changed the implementation to reuse the same DiagnosticsEngine as otherwise warnings can't be enabled or disabled with command-line flags. llvm-svn: 197388
* Move the input files for the unnecessary-module-map-parsing test to Inputs.Manuel Klimek2013-12-132-0/+4
| | | | | | | Needed to change rename.m to set the right include path so we don't import a broken module due to recursive module checking. llvm-svn: 197222
* Add file missing from r197034.Daniel Jasper2013-12-111-0/+1
| | | | llvm-svn: 197035
* Change layering warning tests to not actually build modules.Daniel Jasper2013-12-111-0/+2
| | | | | | | | | | | | | Specifically, we want to warn only for direct layering violations for the modules we are calling clang on. This temporarily unblocks http://llvm-reviews.chandlerc.com/D2374 Once that is in, we'll also want to investigate whether to check the layering in the build step of modules that we build transitively. llvm-svn: 197021
* Allow string literals as module names.Daniel Jasper2013-12-066-1/+33
| | | | | | | | | | | | | | | | | | 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-231-2/+2
| | | | llvm-svn: 195545
* Generate a marker token when entering or leaving a submodule when building aRichard Smith2013-11-235-0/+14
| | | | | | | | | 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
* Include non-explicit submodules in exported module listDmitri Gribenko2013-11-045-0/+33
| | | | | | | | | | | | | | | | 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-283-0/+10
| | | | | | | | | | | | 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-243-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-233-0/+26
| | | | | | | | | | 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-2210-0/+43
| | | | | | | | | | | | | | | | | | | | 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-185-0/+20
| | | | | | | 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-182-0/+13
| | | | | | module. llvm-svn: 192951
* Basic ODR checking for C++ modules:Richard Smith2013-10-183-0/+28
| | | | | | | | | | | | | | | 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-154-0/+27
| | | | | | merged declarations of a class template. llvm-svn: 192746
* C++ modules: merging for enumerations and enumerators with multiple definitionsRichard Smith2013-10-153-0/+18
| | | | | | (eg through template instantiations in multiple modules). llvm-svn: 192740
* Merge common pointers for redeclarations of the same template across modules.Richard Smith2013-10-132-0/+6
| | | | llvm-svn: 192560
* When merging class definitions across modules in C++, merge together fields.Richard Smith2013-10-073-0/+12
| | | | | | | | | 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-241-0/+0
| | | | | | | | | | | | | | | 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-2411-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-114-0/+17
| | | | | | | | | | | | | | | | | | | 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-095-0/+20
| | | | | | | | | | | | 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
OpenPOWER on IntegriCloud