summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix buildbot break after r360195Nemanja Ivanovic2019-05-081-0/+2
| | | | llvm-svn: 360220
* -frewrite-imports: Add support for wildcard rules in umbrella modules withDavid Blaikie2019-05-071-0/+36
| | | | | | | | | | This trips over a few other limitations, but in the interests of incremental development I'm starting here & I'll look at the issues with -verify and filesystem checks (the fact that the behavior depends on the existence of a 'foo' directory even though it shouldn't need it), etc. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D61656 llvm-svn: 360195
* Reduce amount of work ODR hashing does.Richard Trieu2019-05-041-0/+37
| | | | | | | | | | | | | | | When a FunctionProtoType is in the original type in a DecayedType, the decayed type is a PointerType which points back the original FunctionProtoType. The visitor for ODRHashing will attempt to process both Type's, doing double work. By chaining together multiple DecayedType's and FunctionProtoType's, this would result in 2^N Type's visited only N DecayedType's and N FunctionProtoType's exsit. Another bug where VisitDecayedType and VisitAdjustedType did redundant work doubled the work at each level, giving 4^N Type's visited. This patch removed the double work and detects when a FunctionProtoType decays to itself to only check the Type once. This lowers the exponential runtime to linear runtime. Fixes https://bugs.llvm.org/show_bug.cgi?id=41625 llvm-svn: 359960
* Change llvm-{objdump,readobj} -long-option to --long-option or well-known ↵Fangrui Song2019-05-011-2/+2
| | | | | | short options in tests. NFC llvm-svn: 359662
* Skip type units/type uniquing when we know we're only emitting the type once ↵David Blaikie2019-04-252-3/+2
| | | | | | | | | | | | | | | (vtable-based emission when triggered by a strong vtable, with -fno-standalone-debug) (this would regress size without a corresponding LLVM change that avoids putting other user defined types inside type units when they aren't in their own type units - instead emitting declarations inside the type unit and a definition in the primary CU) Reviewers: aprantl Differential Revision: https://reviews.llvm.org/D61079 llvm-svn: 359235
* Fix bug 37903:MS ABI: handle inline static data member and inline variable ↵Jennifer Yu2019-04-251-1/+0
| | | | | | as template static data member llvm-svn: 359212
* Modules: Adopt template parameters for variable templates to set their decl ↵David Blaikie2019-04-191-7/+5
| | | | | | | | | | | context correctly Exposed by a related bug about visibility of default arguments of nested templates - without the correct decl context, default template parameters of variable templates nested in classes would have incorrect visibility computed. llvm-svn: 358796
* Modules: Search for a visible definition of the decl context when computing ↵David Blaikie2019-04-1914-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | visibility of a default template parameter The code is/was already correct for the case where a parameter is a parameter of its enclosing lexical DeclContext (functions and classes). But for other templates (alias and variable templates) they don't create their own scope to be members of - in those cases, they parameter should be considered visible if any definition of the lexical decl context is visible. [this should cleanup the failure on the libstdc++ modules buildbot] [this doesn't actually fix the variable template case for a secondary/compounding reason (its lexical decl context is incorrectly considered to be the translation unit)] Test covers all 4 kinds of templates with default args, including a regression test for the still broken variable template case. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D60892 llvm-svn: 358795
* [C++20] Implement context-sensitive header-name lexing and pp-import parsing ↵Richard Smith2019-04-112-5/+5
| | | | | | in the preprocessor. llvm-svn: 358231
* Remove an unnecessary -f when cp'ing to a file that was just deleted. NFC.Benjamin Kramer2019-03-111-1/+1
| | | | llvm-svn: 355819
* Fix slashes in path references in -Rmodule-import test from r355778Duncan P. N. Exon Smith2019-03-092-29/+29
| | | | | | | Fixup for r355778 to fix all the Windows bots. Apparently I already forgot the lesson from r355482 :/. llvm-svn: 355779
* Modules: Invalidate out-of-date PCMs as they're discoveredDuncan P. N. Exon Smith2019-03-0910-0/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Leverage the InMemoryModuleCache to invalidate a module the first time it fails to import (and to lock a module as soon as it's built or imported successfully). For implicit module builds, this optimizes importing deep graphs where the leaf module is out-of-date; see example near the end of the commit message. Previously the cache finalized ("locked in") all modules imported so far when starting a new module build. This was sufficient to prevent loading two versions of the same module, but was somewhat arbitrary and hard to reason about. Now the cache explicitly tracks module state, where each module must be one of: - Unknown: module not in the cache (yet). - Tentative: module in the cache, but not yet fully imported. - ToBuild: module found on disk could not be imported; need to build. - Final: module in the cache has been successfully built or imported. Preventing repeated failed imports avoids variation in builds based on shifting filesystem state. Now it's guaranteed that a module is loaded from disk exactly once. It now seems safe to remove FileManager::invalidateCache, but I'm leaving that for a later commit. The new, precise logic uncovered a pre-existing problem in the cache: the map key is the module filename, and different contexts use different filenames for the same PCM file. (In particular, the test Modules/relative-import-path.c does not build without this commit. r223577 started using a relative path to describe a module's base directory when importing it within another module. As a result, the module cache sees an absolute path when (a) building the module or importing it at the top-level, and a relative path when (b) importing the module underneath another one.) The "obvious" fix is to resolve paths using FileManager::getVirtualFile and change the map key for the cache to a FileEntry, but some contexts (particularly related to ASTUnit) have a shorter lifetime for their FileManager than the InMemoryModuleCache. This is worth pursuing further in a later commit; perhaps by tying together the FileManager and InMemoryModuleCache lifetime, or moving the in-memory PCM storage into a VFS layer. For now, use the PCM's base directory as-written for constructing the filename to check the ModuleCache. Example ======= To understand the build optimization, first consider the build of a module graph TU -> A -> B -> C -> D with an empty cache: TU builds A' A' builds B' B' builds C' C' builds D' imports D' B' imports C' imports D' A' imports B' imports C' imports D' TU imports A' imports B' imports C' imports D' If we build TU again, where A, B, C, and D are in the cache and D is out-of-date, we would previously get this build: TU imports A imports B imports C imports D (out-of-date) TU builds A' A' imports B imports C imports D (out-of-date) builds B' B' imports C imports D (out-of-date) builds C' C' imports D (out-of-date) builds D' imports D' B' imports C' imports D' A' imports B' imports C' imports D' TU imports A' imports B' imports C' imports D' After this commit, we'll immediateley invalidate A, B, C, and D when we first observe that D is out-of-date, giving this build: TU imports A imports B imports C imports D (out-of-date) TU builds A' // The same graph as an empty cache. A' builds B' B' builds C' C' builds D' imports D' B' imports C' imports D' A' imports B' imports C' imports D' TU imports A' imports B' imports C' imports D' The new build matches what we'd naively expect, pretty closely matching the original build with the empty cache. rdar://problem/48545366 llvm-svn: 355778
* Modules: Rename MemoryBufferCache to InMemoryModuleCacheDuncan P. N. Exon Smith2019-03-091-1/+1
| | | | | | | | | | | | | Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777
* Fix slashes in path references in -Rmodule-import test from r355477Duncan P. N. Exon Smith2019-03-061-17/+17
| | | | | | | Fixup for r355477 to fix the Windows bot: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/16217 llvm-svn: 355482
* Modules: Add -Rmodule-importDuncan P. N. Exon Smith2019-03-067-4/+56
| | | | | | | | | | | | | | | | | | Add a remark for importing modules. Depending on whether this is a direct import (into the TU being built by this compiler instance) or transitive import (into an already-imported module), the diagnostic has two forms: importing module 'Foo' from 'path/to/Foo.pcm' importing module 'Foo' into 'Bar' from 'path/to/Foo.pcm' Also drop a redundant FileCheck invocation in Rmodule-build.m that was using -Reverything, since the notes from -Rmodule-import were confusing it. https://reviews.llvm.org/D58891 llvm-svn: 355477
* Relax assertion to account for private framework modules, too.Adrian Prantl2019-02-151-3/+3
| | | | | | rdar://problem/48116069 llvm-svn: 354165
* -gmodules: Don't emit incomplete breadcrumbs pointing to nonexistant PCM files.Adrian Prantl2019-02-081-0/+16
| | | | | | | | | | | | | | When a module name is specified as -fmodule-name, that module gets a clang::Module object, but it won't actually be built or imported; it will be textual. CGDebugInfo wouldn't detect this and them emit a DICompileUnit that had a hash but no name and that confused both dsymutil, LLDB, and myself. rdar://problem/47926508 Differential Revision: https://reviews.llvm.org/D57976 llvm-svn: 353578
* [opaque pointer types] Cleanup CGBuilder's Create*GEP.James Y Knight2019-02-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Some of these functions take some extraneous arguments, e.g. EltSize, Offset, which are computable from the Type and DataLayout. Add some asserts to ensure that the computed values are consistent with the passed-in values, in preparation for eliminating the extraneous arguments. This also asserts that the Type is an Array for the calls named "Array" and a Struct for the calls named "Struct". Then, correct a couple of errors: 1. Using CreateStructGEP on an array type. (this causes the majority of the test differences, as struct GEPs are created with i32 indices, while array GEPs are created with i64 indices) 2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on x86-64 NACL (which uses 32-bit pointers). Differential Revision: https://reviews.llvm.org/D57766 llvm-svn: 353529
* [modules] Fix handling of initializers for templated global variables.Richard Smith2019-02-051-0/+242
| | | | | | | | | | | | | | | For global variables with unordered initialization that are instantiated within a module, we previously did not emit the global (or its initializer) at all unless it was used in the importing translation unit (and sometimes not even then!), leading to misbehavior and link errors. We now emit the initializer for an instantiated global variable with unordered initialization with side-effects in a module into every translation unit that imports the module. This is unfortunate, but mostly matches the behavior of a non-modular compilation and seems to be the best that we can reasonably do. llvm-svn: 353240
* [NFC] Explicitly add -std=c++14 option to tests that rely on the C++14 defaultNemanja Ivanovic2019-02-052-3/+3
| | | | | | | | | | | When Clang/LLVM is built with the CLANG_DEFAULT_STD_CXX CMake macro that sets the default standard to something other than C++14, there are a number of lit tests that fail as they rely on the C++14 default. This patch just adds the language standard option explicitly to such test cases. Differential revision: https://reviews.llvm.org/D57581 llvm-svn: 353163
* Fix the behavior of clang's -w flag.James Y Knight2019-01-291-5/+5
| | | | | | | | | | It is intended to disable _all_ warnings, even those upgraded to errors via `-Werror=warningname` or `#pragma clang diagnostic error' Fixes: https://llvm.org/PR38231 Differential Revision: https://reviews.llvm.org/D53199 llvm-svn: 352535
* CodeGen: fix autolink emission on ELFSaleem Abdulrasool2019-01-051-2/+2
| | | | | | | | | The autolinking extension for ELF uses a slightly different format for encoding the autolink information compared to COFF and MachO. Account for this in the CGM to ensure that we do not assert when emitting assembly or an object file. llvm-svn: 350476
* Reapply "Avoid emitting redundant or unusable directories in DIFile metadata ↵Adrian Prantl2018-12-061-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | entries."" This reverts commit r348280 and reapplies D55085 without modifications. Original commit message: Avoid emitting redundant or unusable directories in DIFile metadata entries. As discussed on llvm-dev recently, Clang currently emits redundant directories in DIFile entries, such as .file 1 "/Volumes/Data/llvm" "/Volumes/Data/llvm/tools/clang/test/CodeGen/debug-info-abspath.c" This patch looks at any common prefix between the compilation directory and the (absolute) file path and strips the redundant part. More importantly it leaves the compilation directory empty if the two paths have no common prefix. After this patch the above entry is (assuming a compilation dir of "/Volumes/Data/llvm/_build"): .file 1 "/Volumes/Data/llvm" "tools/clang/test/CodeGen/debug-info-abspath.c" When building the FileCheck binary with debug info, this patch makes the build artifacts ~1kb smaller. Differential Revision: https://reviews.llvm.org/D55085 llvm-svn: 348513
* Diagnose friend function template redefinitions.Serge Pavlov2018-12-061-0/+2
| | | | | | | | | | | | | | Friend function template defined in a class template becomes available if the enclosing class template is instantiated. Until the function template is used, it does not have a body, but still is considered a definition for the purpose of redeclaration checks. This change modifies redefinition check so that it can find the friend function template definitions in instantiated classes. Differential Revision: http://reviews.llvm.org/D21508 llvm-svn: 348473
* [test] Disable Modules/prune.m on NetBSD as it requires 'touch -a'Michal Gorny2018-12-051-0/+3
| | | | llvm-svn: 348356
* Revert "Avoid emitting redundant or unusable directories in DIFile metadata ↵Ilya Biryukov2018-12-041-3/+1
| | | | | | | | | | entries." This reverts commit r348154 and follow-up commits r348211 and r3248213. Reason: the original commit broke compiler-rt tests and a follow-up fix (r348203) broke our integrate and was reverted. llvm-svn: 348280
* Relax tests to also work on WindowsAdrian Prantl2018-12-031-1/+3
| | | | llvm-svn: 348211
* Avoid emitting redundant or unusable directories in DIFile metadata entries.Adrian Prantl2018-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | As discussed on llvm-dev recently, Clang currently emits redundant directories in DIFile entries, such as .file 1 "/Volumes/Data/llvm" "/Volumes/Data/llvm/tools/clang/test/CodeGen/debug-info-abspath.c" This patch looks at any common prefix between the compilation directory and the (absolute) file path and strips the redundant part. More importantly it leaves the compilation directory empty if the two paths have no common prefix. After this patch the above entry is (assuming a compilation dir of "/Volumes/Data/llvm/_build"): .file 1 "/Volumes/Data/llvm" "tools/clang/test/CodeGen/debug-info-abspath.c" When building the FileCheck binary with debug info, this patch makes the build artifacts ~1kb smaller. Differential Revision: https://reviews.llvm.org/D55085 llvm-svn: 348154
* [-gmodules] Honor -fdebug-prefix-map in the debug info inside PCMs.Adrian Prantl2018-11-291-0/+23
| | | | | | | | | | | | This patch passes -fdebug-prefix-map (a feature for renaming source paths in the debug info) through to the per-module codegen options and adds the debug prefix map to the module hash. <rdar://problem/46045865> Differential Revision: https://reviews.llvm.org/D55037 llvm-svn: 347926
* CGDecl::emitStoresForConstant fix synthesized constant's nameJF Bastien2018-11-151-4/+4
| | | | | | | | | | | | Summary: The name of the synthesized constants for constant initialization was using mangling for statics, which isn't generally correct and (in a yet-uncommitted patch) causes the mangler to assert out because the static ends up trying to mangle function parameters and this makes no sense. Instead, mangle to `"__const." + FunctionName + "." + DeclName`. Reviewers: rjmccall Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D54055 llvm-svn: 346915
* [HeaderSearch] loadSubdirectoryModuleMaps should respect -working-directoryAlex Lorenz2018-11-143-0/+19
| | | | | | | | | | | Include search paths can be relative paths. The loadSubdirectoryModuleMaps function should account for that and respect the -working-directory parameter given to Clang. rdar://46045849 Differential Revision: https://reviews.llvm.org/D54503 llvm-svn: 346822
* Fix test from r346439 to also work on Windows due to path separator differences.Douglas Yung2018-11-091-1/+1
| | | | llvm-svn: 346468
* [Frontend/Modules] Show diagnostics on prebuilt module configuration ↵David Blaikie2018-11-081-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | mismatch too The current version only emits the below error for a module (attempted to be loaded) from the `prebuilt-module-path`: ``` error: module file blabla.pcm cannot be loaded due to a configuration mismatch with the current compilation [-Wmodule-file-config-mismatch] ``` With this change, if the prebuilt module is used, we allow the proper diagnostic behind the configuration mismatch to be shown. ``` error: POSIX thread support was disabled in PCH file but is currently enabled error: module file blabla.pcm cannot be loaded due to a configuration mismatch with the current compilation [-Wmodule-file-config-mismatch] ``` (A few lines later an error is emitted anyways, so there is no reason not to complain for configuration mismatches if a config mismatch is found and kills the build.) Reviewed By: dblaikie Tags: #clang Differential Revision: https://reviews.llvm.org/D53334 llvm-svn: 346439
* Reapply "Fix regression in behavior of clang -x c++-header -fmodule-name=XXX"Benjamin Kramer2018-11-051-0/+17
| | | | | | | | | | | | | This reverts commit r345963. We have a path forward now. Original commit message: The driver accidentally stopped passing the input filenames on to -cc1 in this mode due to confusion over what action was being requested. This change also fixes a couple of crashes I encountered when passing multiple files to such a -cc1 invocation. llvm-svn: 346130
* Add an explicit -std=c++14 to this test.Adrian Prantl2018-11-021-4/+4
| | | | | | rdar://problem/45642490 llvm-svn: 346048
* Revert "Fix regression in behavior of clang -x c++-header -fmodule-name=XXX"Ilya Biryukov2018-11-021-17/+0
| | | | | | | | | | This reverts commit r345803 and r345915 (a follow-up fix to r345803). Reason: r345803 blocks our internal integrate because of the new warnings showing up in too many places. The fix is actually correct, we will reland it after figuring out how to integrate properly. llvm-svn: 345963
* Fix regression in behavior of clang -x c++-header -fmodule-name=XXXRichard Smith2018-11-011-0/+17
| | | | | | | | | | | | -fsyntax-only. The driver accidentally stopped passing the input filenames on to -cc1 in this mode due to confusion over what action was being requested. This change also fixes a couple of crashes I encountered when passing multiple files to such a -cc1 invocation. llvm-svn: 345803
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-301-1/+1
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* [VFS] Remove 'ignore-non-existent-contents' attribute for YAML-based VFS.Volodymyr Sapsai2018-10-245-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 'ignore-non-existent-contents' stopped working after r342232 in a way that the actual attribute value isn't used and it works as if it is always `true`. Common use case for VFS iteration is iterating through files in umbrella directories for modules. Ability to detect if some VFS entries point to non-existing files is nice but non-critical. Instead of adding back support for `'ignore-non-existent-contents': false` I am removing the attribute, because such scenario isn't used widely enough and stricter checks don't provide enough value to justify the maintenance. rdar://problem/45176119 Reviewers: bruno Reviewed By: bruno Subscribers: hiraditya, dexonsmith, sammccall, cfe-commits Differential Revision: https://reviews.llvm.org/D53228 llvm-svn: 345212
* Debug Info (-gmodules): emit full types for non-anchored template ↵Adrian Prantl2018-10-246-2/+122
| | | | | | | | | | | | | | | | | specializations Before this patch, clang would emit a (module-)forward declaration for template instantiations that are not anchored by an explicit template instantiation, but still are guaranteed to be available in an imported module. Unfortunately detecting the owning module doesn't reliably work when local submodule visibility is enabled and the template is inside a cross-module namespace. This make clang debuggable again with -gmodules and LSV enabled. rdar://problem/41552377 llvm-svn: 345109
* Fix an assert in -Wquoted-include-in-framework-headerErik Pilkington2018-09-203-0/+5
| | | | | | | | Fixes rdar://43692300 Differential revision: https://reviews.llvm.org/D52253 llvm-svn: 342679
* [Modules] Add platform and environment features to requires clauseBruno Cardoso Lopes2018-09-181-0/+79
| | | | | | | | | | | | | Allows module map writers to add build requirements based on platform/os. This helps when target features and language dialects aren't enough to conditionalize building a module, among other things, it allow module maps for different platforms to live in the same file. rdar://problem/43909745 Differential Revision: https://reviews.llvm.org/D51910 llvm-svn: 342499
* [modules] Support use of -E on modules built from the command line.Richard Smith2018-09-151-0/+5
| | | | llvm-svn: 342306
* [modules] Frontend support for building a header module from a list ofRichard Smith2018-09-153-0/+52
| | | | | | headaer files. llvm-svn: 342304
* [ODRHash] Fix early exit that skipped code.Richard Trieu2018-09-141-0/+1
| | | | | | | | | | There is a bit of code at the end of AddDeclaration that should be run on every exit of the function. However, there was an early exit beforehand that could be triggered, which causes a small amount of data to skip the hashing, leading to false positive mismatch. Use a separate function so that this code is always run. llvm-svn: 342199
* Print correctly dependency paths on WindowsDavid Bolvansky2018-09-131-3/+3
| | | | | | | | | | | | | | | | | | | Summary: Before: main.o: main.c ../include/lib\test.h After: main.o: main.c ../include/lib/test.h Fixes PR38877 Reviewers: zturner Subscribers: xbolva00, cfe-commits Differential Revision: https://reviews.llvm.org/D51847 llvm-svn: 342139
* Track definition merging on the canonical declaration even when localRichard Smith2018-09-121-0/+34
| | | | | | | | | | | | | | submodule visibility is disabled. Attempting to pick a specific declaration to make visible when the module containing the merged declaration becomes visible is error-prone, as we don't yet know which declaration we'll choose to be the definition when we are informed of the merging. This reinstates r342019, reverted in r342020. The regression previously observed after this commit was fixed in r342096. llvm-svn: 342097
* When we leave a module header, make that header visible in itsRichard Smith2018-09-125-0/+32
| | | | | | includer's context, even if its overall module is unavailable. llvm-svn: 342096
* Revert r342019, "Track definition merging on the canonical declarationRichard Smith2018-09-121-34/+0
| | | | | | | | | even when [...]" Further testing has revealed that this causes build breaks during explicit module compilations. llvm-svn: 342020
* Track definition merging on the canonical declaration even when localRichard Smith2018-09-121-0/+34
| | | | | | | | | | | submodule visibility is disabled. Attempting to pick a specific declaration to make visible when the module containing the merged declaration becomes visible is error-prone, as we don't yet know which declaration we'll choose to be the definition when we are informed of the merging. llvm-svn: 342019
OpenPOWER on IntegriCloud