summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
* [ODRHash] Fix null pointer dereference for ObjC selectors with empty slots.Volodymyr Sapsai2019-06-281-0/+31
| | | | | | | | | | | | | | | | | `Selector::getIdentifierInfoForSlot` returns NULL if a slot has no corresponding identifier. Add a boolean to the hash and a NULL check. rdar://problem/51615164 Reviewers: rtrieu Reviewed By: rtrieu Subscribers: dexonsmith, cfe-commits, jkorous Differential Revision: https://reviews.llvm.org/D63789 llvm-svn: 364664
* [ODRHash] Skip some typedef types.Richard Trieu2019-06-221-1/+62
| | | | | | | | | | | | | | | In some cases, a typedef only strips aways a keyword for a type, keeping the same name as the root record type. This causes some confusion when the type is defined in one modules but only forward declared in another. Skipping the typedef and going straight to the record will avoid this issue. typedef struct S {} S; S* s; // S is TypedefType here struct S; S* s; // S is RecordType here llvm-svn: 364119
* [Clang] Rename -split-dwarf-file to -split-dwarf-outputAaron Puchert2019-06-151-1/+1
| | | | | | | | | | | | | | | | | | Summary: This is the first in a series of changes trying to align clang -cc1 flags for Split DWARF with those of llc. The unfortunate side effect of having -split-dwarf-output for single file Split DWARF will disappear again in a subsequent change. The change is the result of a discussion in D59673. Reviewers: dblaikie, echristo Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D63130 llvm-svn: 363494
* Fix r361428 for Windows buildbots/manglingDavid Blaikie2019-05-221-1/+1
| | | | llvm-svn: 361439
* Fix new enum-codegen.cpp testReid Kleckner2019-05-221-1/+1
| | | | llvm-svn: 361438
* Modules: Code generation of enum constants for merged enum definitionsDavid Blaikie2019-05-221-0/+36
| | | | | | | | | | | | | | | Found in a bootstrap of LLVM with implicit modules, resulting in a deadlock of some Orc unit tests with libstdc++ 8.1. An enum was used as part of the implementation of std::recursive_mutex and this bug resulted in the constant initialization of zero instead of the desired non-zero value. => Badness. Richard Smith tells me neither of these fields are necessarily canonical & so using declaresSamEntity is the right solution here (rather than changing both of these Fields to be canonical by construction/from their source) llvm-svn: 361428
* [ELF] Implement Dependent Libraries FeatureBen Dunbobbin2019-05-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a limited form of autolinking primarily designed to allow either the --dependent-library compiler option, or "comment lib" pragmas ( https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically add the specified library to the link when processing the input file generated by the compiler. Currently this extension is unique to LLVM and LLD. However, care has been taken to design this feature so that it could be supported by other ELF linkers. The design goals were to provide: - A simple linking model for developers to reason about. - The ability to to override autolinking from the linker command line. - Source code compatibility, where possible, with "comment lib" pragmas in other environments (MSVC in particular). Dependent library support is implemented differently for ELF platforms than on the other platforms. Primarily this difference is that on ELF we pass the dependent library specifiers directly to the linker without manipulating them. This is in contrast to other platforms where they are mapped to a specific linker option by the compiler. This difference is a result of the greater variety of ELF linkers and the fact that ELF linkers tend to handle libraries in a more complicated fashion than on other platforms. This forces us to defer handling the specifiers to the linker. In order to achieve a level of source code compatibility with other platforms we have restricted this feature to work with libraries that meet the following "reasonable" requirements: 1. There are no competing defined symbols in a given set of libraries, or if they exist, the program owner doesn't care which is linked to their program. 2. There may be circular dependencies between libraries. The binary representation is a mergeable string section (SHF_MERGE, SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES (0x6fff4c04). The compiler forms this section by concatenating the arguments of the "comment lib" pragmas and --dependent-library options in the order they are encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs sections with the normal mergeable string section rules. As an example, #pragma comment(lib, "foo") would result in: .section ".deplibs","MS",@llvm_dependent_libraries,1 .asciz "foo" For LTO, equivalent information to the contents of a the .deplibs section can be retrieved by the LLD for bitcode input files. LLD processes the dependent library specifiers in the following way: 1. Dependent libraries which are found from the specifiers in .deplibs sections of relocatable object files are added when the linker decides to include that file (which could itself be in a library) in the link. Dependent libraries behave as if they were appended to the command line after all other options. As a consequence the set of dependent libraries are searched last to resolve symbols. 2. It is an error if a file cannot be found for a given specifier. 3. Any command line options in effect at the end of the command line parsing apply to the dependent libraries, e.g. --whole-archive. 4. The linker tries to add a library or relocatable object file from each of the strings in a .deplibs section by; first, handling the string as if it was specified on the command line; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. 5. A new command line option --no-dependent-libraries tells LLD to ignore the dependent libraries. Rationale for the above points: 1. Adding the dependent libraries last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme. 2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution. 3. It seems useful for the user to be able to apply command line options which will affect all of the dependent libraries. There is a potential problem of surprise for developers, who might not realize that these options would apply to these "invisible" input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require. 4. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order. 5. I considered adding finer grained control over which dependent libraries were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can fall back to using the command line directly. RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html. Differential Revision: https://reviews.llvm.org/D60274 llvm-svn: 360984
* [X86] Make `x86intrin.h`, `immintrin.h` includable with `-fno-gnu-inline-asm`.Volodymyr Sapsai2019-05-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Currently `immintrin.h` includes `pconfigintrin.h` and `sgxintrin.h` which contain inline assembly. It causes failures when building with the flag `-fno-gnu-inline-asm`. Fix by excluding functions with inline assembly when this extension is disabled. So far there was no need to support `_pconfig_u32`, `_enclu_u32`, `_encls_u32`, `_enclv_u32` on platforms that require `-fno-gnu-inline-asm`. But if developers start using these functions, they'll have compile-time undeclared identifier errors which is preferrable to runtime errors. rdar://problem/49540880 Reviewers: craig.topper, GBuella, rnk, echristo Reviewed By: rnk Subscribers: jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D61621 llvm-svn: 360630
* Replace lit feature keyword 'non-ms-sdk' with 'ms-sdk'; eliminatePaul Robinson2019-05-101-1/+2
| | | | | | 'non-ps4-sdk' and use just 'ps4'. llvm-svn: 360425
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-092-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* Allow test to pass after 2030.Aaron Ballman2019-05-081-2/+2
| | | | | | Patch by Bernhard M. Wiedemann. llvm-svn: 360254
* 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
OpenPOWER on IntegriCloud