summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
...
* [ODRHash] Add TemplateArgument kind to hash.Richard Trieu2017-06-131-0/+18
| | | | llvm-svn: 305328
* [ODRHash] Add diagnostic messages for typedef and type alias.Richard Trieu2017-06-121-0/+102
| | | | llvm-svn: 305238
* IR: Replace the "Linker Options" module flag with "llvm.linker.options" ↵Peter Collingbourne2017-06-123-10/+5
| | | | | | | | | | named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
* Revert r305110 to fix buildbotRichard Trieu2017-06-091-18/+0
| | | | llvm-svn: 305130
* Add -frewrite-imports flag.Richard Smith2017-06-091-0/+26
| | | | | | | | If specified, when preprocessing, the contents of imported .pcm files will be included in preprocessed output. The resulting preprocessed file can then be compiled standalone without the module sources or .pcm files. llvm-svn: 305116
* [ODRHash] Add support for TemplateArgument types.Richard Trieu2017-06-091-0/+18
| | | | | | | Recommit r304592 that was reverted in r304618. r305104 should have fixed the issue. llvm-svn: 305110
* Add #pragma clang module build/endbuild pragmas for performing a module buildRichard Smith2017-06-091-0/+35
| | | | | | | | | | | | | | | as part of a compilation. This is intended for two purposes: 1) Writing self-contained test cases for modules: we can now write a single source file test that builds some number of module files on the side and imports them. 2) Debugging / test case reduction. A single-source testcase is much more amenable to reduction, compared to a VFS tarball or .pcm files. llvm-svn: 305101
* Retain header search and preprocessing options from AST file when emittingRichard Smith2017-06-061-0/+8
| | | | | | preprocessed text for an AST file. llvm-svn: 304756
* Fix crash when an 'import a module' TypoCorrection has its CorrectionDeclsRichard Smith2017-06-053-0/+14
| | | | | | | | | | | | replaced by visible decls. Make sure that all paths through checkCorrectionVisibility set the RequiresImport flag appropriately, so we don't end up using a stale value. Patch by Jorge Gorbe! Differential Revision: https://reviews.llvm.org/D30963 llvm-svn: 304745
* Factor out and unify emission of "module is unavailable" diagnostics.Richard Smith2017-06-054-15/+25
| | | | | | Inspired by post-commit review of r304190. llvm-svn: 304728
* Attempt to fix Windows buildbot failure due to mismatching directory ↵Richard Smith2017-06-051-2/+11
| | | | | | separators in preprocessed output. llvm-svn: 304727
* Rather than rejecting attempts to run preprocessor-only actions on AST files,Richard Smith2017-06-051-1/+6
| | | | | | | | | | replay the steps taken to create the AST file with the preprocessor-only action installed to produce preprocessed output. This can be used to produce the preprocessed text for an existing .pch or .pcm file. llvm-svn: 304726
* Revert r304592Richard Trieu2017-06-031-18/+0
| | | | | | | r304592 - [ODRHash] Add support for TemplateArgument types. Possibly causing one of the errors in modules build bot. llvm-svn: 304618
* [ODRHash] Add support for TemplateArgument types.Richard Trieu2017-06-021-0/+18
| | | | llvm-svn: 304592
* ASTPrinter: Objective-C method declarations don't need a space afterAlex Lorenz2017-06-021-2/+2
| | | | | | | | the return type rdar://32332039 llvm-svn: 304553
* Support lazy stat'ing of files referenced by module maps.Richard Smith2017-06-029-3/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for a `header` declaration in a module map to specify certain `stat` information (currently, size and mtime) about that header file. This has two purposes: - It removes the need to eagerly `stat` every file referenced by a module map. Instead, we track a list of unresolved header files with each size / mtime (actually, for simplicity, we track submodules with such headers), and when attempting to look up a header file based on a `FileEntry`, we check if there are any unresolved header directives with that `FileEntry`'s size / mtime and perform deferred `stat`s if so. - It permits a preprocessed module to be compiled without the original files being present on disk. The only reason we used to need those files was to get the `stat` information in order to do header -> module lookups when using the module. If we're provided with the `stat` information in the preprocessed module, we can avoid requiring the files to exist. Unlike most `header` directives, if a `header` directive with `stat` information has no corresponding on-disk file the enclosing module is *not* marked unavailable (so that behavior is consistent regardless of whether we've resolved a header directive, and so that preprocessed modules don't get marked unavailable). We could actually do this for all `header` directives: the only reason we mark the module unavailable if headers are missing is to give a diagnostic slightly earlier (rather than waiting until we actually try to build the module / load and validate its .pcm file). Differential Revision: https://reviews.llvm.org/D33703 llvm-svn: 304515
* [Modules] Handle sanitizer feature mismatches when importing modulesVedant Kumar2017-06-013-0/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it an error to have a mismatch between the enabled sanitizers in a CU, and in any module being imported into the CU. Only mismatches between non-modular sanitizers are treated as errors. This patch also includes non-modular sanitizers in module hashes, in order to ensure module rebuilds occur when -fsanitize=X is toggled on and off for non-modular sanitizers, and to cut down on module rebuilds when the option is toggled for modular sanitizers. This fixes a longstanding issue with implicit modules and sanitizers, which Duncan originally diagnosed. When building with implicit modules it's possible to hit a scenario where modules are built without -fsanitize=address, and are subsequently imported into CUs with -fsanitize=address enabled. This causes strange failures at runtime. The case Duncan found affects libcxx, since its vector implementation behaves differently when ASan is enabled. Implicit module builds should "just work" when -fsanitize=X is toggled on and off across multiple compiler invocations, which is what this patch does. Differential Revision: https://reviews.llvm.org/D32724 llvm-svn: 304463
* [modules] When compiling a preprocessed module map, look for headers relativeRichard Smith2017-05-312-5/+7
| | | | | | | | | | | | to the original module map. Also use the path and name of the original module map when emitting that information into the .pcm file. The upshot of this is that the produced .pcm file will track information for headers in their original locations (where the module was preprocessed), not relative to whatever directory the preprocessed module map was in when it was built. llvm-svn: 304346
* [ODRHash] Support TemplateSpecializationTypeRichard Trieu2017-05-311-0/+34
| | | | llvm-svn: 304261
* Add an explicit -std= to test to unbreak on PS4 targets.Richard Smith2017-05-301-1/+1
| | | | llvm-svn: 304237
* Diagnose attempts to build a preprocessed module that defines an unavailable ↵Richard Smith2017-05-301-0/+12
| | | | | | | | | submodule. The errors we would otherwise get are incomprehensible, as we would enter the module but not make its contents visible to itself. llvm-svn: 304190
* [modules] When we #include a local submodule header that we've already built,Richard Smith2017-05-305-0/+72
| | | | | | | | | | and it has an include guard, produce callbacks for a module import, not for a skipped non-modular header. Fixes -E output when preprocessing a module to list these cases as a module import, rather than suppressing the #include and losing the import side effect. llvm-svn: 304183
* [coroutines] Support "coroutines" feature in module map requires clauseEric Fiselier2017-05-284-1/+26
| | | | | | | | | | | | | | Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33538 llvm-svn: 304107
* Revert "[coroutines] Support "coroutines" feature in module map requires clause"Eric Fiselier2017-05-274-26/+1
| | | | | | This reverts commit r304054. llvm-svn: 304057
* [coroutines] Support "coroutines" feature in module map requires clauseEric Fiselier2017-05-274-1/+26
| | | | | | | | | | | | | | Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33538 llvm-svn: 304054
* [Modules] Fix overly conservative assertion for import diagnosticBruno Cardoso Lopes2017-05-233-0/+25
| | | | | | | | | | | | | | | | We currenltly assert when want to diagnose a missing import and the decl in question is already visible. It turns out that the decl in question might be visible because another decl from the same module actually made the module visible in a previous error diagnostic. Remove the assertion and avoid re-exporting the module if it's already visible. rdar://problem/27975402 Differential Revision: https://reviews.llvm.org/D32828 llvm-svn: 303705
* [modules] Simplify module macro handling in non-local-submodule-visibility mode.Richard Smith2017-05-191-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When reaching the end of a module, we used to convert its macros to ModuleMacros but also leave them in the MacroDirective chain for the identifier. This meant that every lookup of such a macro would find two (identical) definitions. It also made it difficult to determine the correct owner for a macro when reaching the end of a module: the most recent MacroDirective in the chain could be from an #included submodule rather than the current module. Simplify this: whenever we convert a MacroDirective to a ModuleMacro when leaving a module, clear out the MacroDirective chain for that identifier, and just rely on the ModuleMacro to provide the macro definition information. (We don't want to do this for local submodule visibility mode, because in that mode we maintain a distinct MacroDirective chain for each submodule, and we need to keep around the prior MacroDirective in case we re-enter the submodule -- for instance, if its header is #included more than once in a module build, we need the include guard directive to stick around. But the problem doesn't arise in this case for the same reason: each submodule has its own MacroDirective chain, so the macros don't leak out of submodules in the first place.) This reinstates r302932, reverted in r302947, with a fix for a bug that resulted in us sometimes losing macro definitions due to failing to clear out the overridden module macro list when promoting a directive to a module macro. llvm-svn: 303468
* [ODRHash] Revert r303450 to fix buildbotRichard Trieu2017-05-191-102/+0
| | | | | | | r303450 [ODRHash] Support TemplateName and TemplateArgument llvm-svn: 303459
* [ODRHash] Support TemplateName and TemplateArgumentRichard Trieu2017-05-191-0/+102
| | | | llvm-svn: 303450
* When we enter a module within a linkage specification, switch the linkageRichard Smith2017-05-181-0/+25
| | | | | | | | | | specification and the TU to the new module. This is necessary to get the module ownership correct for entities that we temporarily hang off the TranslationUnitDecl, such as template parameters and function parameters. llvm-svn: 303373
* [modules] Switch from inferring owning modules based on source location toRichard Smith2017-05-181-6/+8
| | | | | | | | | | | | | | | inferring based on the current module at the point of creation. This should result in no functional change except when building a preprocessed module (or more generally when using #pragma clang module begin/end to switch module in the middle of a file), in which case it allows us to correctly track the owning module for declarations. We can't map from FileID to module in the preprocessed module case, since all modules would have the same FileID. There are still a couple of remaining places that try to infer a module from a source location; I'll clean those up in follow-up changes. llvm-svn: 303322
* [Lexer] Ensure that the token is not an annotation token whenAlex Lorenz2017-05-173-0/+14
| | | | | | | | | | | retrieving the identifer info for an Objective-C keyword This commit fixes an assertion that's triggered in getIdentifier when the token is an annotation token. rdar://32225463 llvm-svn: 303246
* [ODRHash] Support NestedNameSpecifierRichard Trieu2017-05-171-0/+159
| | | | llvm-svn: 303233
* [ODRHash] Support more types in the ODR checker.Richard Trieu2017-05-171-0/+72
| | | | | | Added support for TagType, TypeWithKeyword, and all children types. llvm-svn: 303231
* [modules] When creating a declaration, cache its owning module immediatelyRichard Smith2017-05-173-1/+23
| | | | | | | | | | | | | | | rather than waiting until it's queried. Currently this is only applied to local submodule visibility mode, as we don't yet allocate storage for the owning module in non-local-visibility modules compilations. This reinstates r302965, reverted in r303037, with a fix for the reported crash, which occurred when reparenting a local declaration to be a child of a hidden imported declaration (specifically during template instantiation). llvm-svn: 303224
* Module Debug Info: Emit namespaced C++ forward decls in the correct module.Adrian Prantl2017-05-114-0/+33
| | | | | | | | | | | | The AST merges NamespaceDecls, but for module debug info it is important to put a namespace decl (or rather its children) into the correct (sub-)module, so we need to use the parent module of the decl that triggered this namespace to be serialized as a second key when looking up DINamespace nodes. rdar://problem/29339538 llvm-svn: 302840
* Add a test that local submodule visibility has no effect on debug infoAdrian Prantl2017-05-111-0/+5
| | | | | | rdar://problem/27876262 llvm-svn: 302809
* Make tests from r302765 windows friendlyBruno Cardoso Lopes2017-05-111-6/+6
| | | | | | | and appease: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/2030 llvm-svn: 302771
* [Sema] Improve redefinition errors pointing to the same headerBruno Cardoso Lopes2017-05-115-0/+50
| | | | | | | | | | | | | | | | | | Diagnostics related to redefinition errors that point to the same header file do not provide much information that helps users fixing the issue. - In the modules context, it usually happens because of non modular includes. - When modules aren't involved it might happen because of the lack of header guards. Enhance diagnostics in these scenarios. Differential Revision: https://reviews.llvm.org/D28832 rdar://problem/31669175 llvm-svn: 302765
* [ODRHash] Loosen checks on typedefs.Richard Trieu2017-05-091-0/+33
| | | | | | | When a type in a class is from a typedef, only check the canonical type. Skip checking the intermediate underlying types. This is in response to PR 32965 llvm-svn: 302505
* [Modules] Allow umbrella frameworks to define private submodules for ↵Bruno Cardoso Lopes2017-05-0911-1/+46
| | | | | | | | | | | | subframeworks In r298391 we fixed the umbrella framework model to work when submodules named "Private" are used. This complements the work by allowing the umbrella framework model to work in general. rdar://problem/31790067 llvm-svn: 302491
* If we are building a module, and we read a second description of the sameRichard Smith2017-05-081-0/+5
| | | | | | | | module from a different module map, ignore it. This happens during builds of preprocessed modules (where it is harmless). llvm-svn: 302463
* Add support for building modules from preprocessed source.Richard Smith2017-05-051-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support this, an optional marker "#pragma clang module contents" is recognized in module map files, and the rest of the module map file from that point onwards is treated as the source of the module. Preprocessing a module map produces the input module followed by the marker and then the preprocessed contents of the module. Ignoring line markers, a preprocessed module might look like this: module A { header "a.h" } #pragma clang module contents #pragma clang module begin A // ... a.h ... #pragma clang module end The preprocessed output generates line markers, which are not accepted by the module map parser, so -x c++-module-map-cpp-output should be used to compile such outputs. A couple of major parts do not work yet: 1) The files that are listed in the module map must exist on disk, in order to build the on-disk header -> module lookup table in the PCM file. To fix this, we need the preprocessed output to track the file size and other stat information we might use to build the lookup table. 2) Declaration ownership semantics don't work properly yet, since mapping from a source location to a module relies on mapping from FileIDs to modules, which we can't do if module transitions can occur in the middle of a file. llvm-svn: 302309
* Add #pragma clang module begin/end pragmas and generate them when ↵Richard Smith2017-05-043-3/+58
| | | | | | | | | | | | | | preprocessing a module. These pragmas are intended to simulate the effect of entering or leaving a file with an associated module. This is not completely implemented yet: declarations between the pragmas will not be attributed to the correct module, but macro visibility is already functional. Modules named by #pragma clang module begin must already be known to clang (in some module map that's either loaded or on the search path). llvm-svn: 302098
* [modules] Round-trip -Werror flag through explicit module build.Richard Smith2017-05-031-8/+30
| | | | | | | | | | | | | | | The intent for an explicit module build is that the diagnostics produced within the module are those that were configured when the module was built, not those that are enabled within a user of the module. This includes diagnostics that don't actually show up until the module is used (for instance, diagnostics produced during template instantiation and weird cases like -Wpadded). We serialized and restored the diagnostic state for individual warning groups, but previously did not track the state for flags like -Werror and -Weverything, which are implemented as separate bits rather than as part of the diagnostics mapping information. llvm-svn: 301992
* [ODRHash] Add support for array and decayed types, and parameter names and ↵Richard Trieu2017-05-021-31/+177
| | | | | | types. llvm-svn: 301989
* clang/test/Modules/diag-flags.cpp: Appease targeting *-win32 with explicit ↵NAKAMURA Takumi2017-05-021-6/+6
| | | | | | | | | triple. Fixes r301846. MicrosoftRecordLayoutBuilder doesn't have ability of -Wpadded. FIXME: Would other diag be available here? llvm-svn: 301898
* New file missed from r301846.Richard Smith2017-05-011-0/+1
| | | | llvm-svn: 301847
* Fix initial diagnostic state setup for an explicit module with no diagnostic ↵Richard Smith2017-05-012-0/+26
| | | | | | | | | | | | pragmas. If a file has no diagnostic pragmas, we build its diagnostic state lazily, but in this case we never set up the root state to be the diagnostic state in which the module was originally built, so the diagnostic flags for files in the module with no diagnostic pragmas were incorrectly based on the user of the module rather than the diagnostic state when the module was built. llvm-svn: 301846
* Put back REQUIRES: system-darwin to fix asan bot.Richard Smith2017-05-015-5/+5
| | | | | | | | | These tests do not appear to be Darwin-specific, and this REQUIRES: appears to be hiding a real bug; this change is just restoring the prior state to get the buildbots happy again while we investigate. (The system-darwin requirement is covered by PR32851.) llvm-svn: 301840
OpenPOWER on IntegriCloud