summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
...
* Module Debugging: Use a nonzero DWO id for precompiled headers.Adrian Prantl2016-01-222-2/+5
| | | | | | | | | | | | | PCH files don't have a module signature and LLVM uses a nonzero DWO id as an indicator for skeleton / module CUs. This change pins the DWO id for PCH files to a known constant value. The correct long-term solution here is to implement a module signature that is an actual dterministic hash (at the moment module signatures are just random nonzero numbers) and then enable this for PCH files as well. <rdar://problem/24290667> llvm-svn: 258507
* Module Debugging: Fine-tune the condition that determines whether a typeAdrian Prantl2016-01-203-1/+19
| | | | | | | | | | | | | can be found in a module. There are externally visible anonymous types that can be found: typedef struct { } s; // I can be found via the typedef. There are anonymous internal types that can be found: namespace { struct s {}; } // I can be found by name. rdar://problem/24199640 llvm-svn: 258272
* Module Debugging: Add Objective-C testcases for anonymous tag decls. (NFC)Adrian Prantl2016-01-193-0/+75
| | | | | | rdar://problem/24199640 llvm-svn: 258252
* Module Debugging: Don't emit external type references to anonymous types.Adrian Prantl2016-01-191-0/+9
| | | | | | | | Even if they exist in the module, they can't be matched with the forward declaration in the object file. <rdar://problem/24199640> llvm-svn: 258251
* Module Debugging: Make sure that anonymous tag decls that define globalAdrian Prantl2016-01-193-0/+24
| | | | | | | | | variables are visited. This shouldn't encourage anyone to put global variables into clang modules. rdar://problem/24199640 llvm-svn: 258250
* Module Debugging: Defer the emission of anonymous tag declsAdrian Prantl2016-01-193-0/+27
| | | | | | | | | | | | | until we are visiting their declcontext. This fixes a regression introduced in r256962: When building debug info for a typdef'd anonymous tag type, we would be visiting the inner anonymous type first thus creating a "typedef changes linkage of anonymous type, but linkage was already computed" error. rdar://problem/24199640 llvm-svn: 258152
* [modules] Don't diagnose a conflict between two using-declarations that name ↵Richard Smith2016-01-124-4/+17
| | | | | | equivalent internal linkage entities. llvm-svn: 257512
* When a tag is declared in prototype scope in C, if we've decided that itRichard Smith2016-01-111-0/+18
| | | | | | | | | | | | | | redeclares an existing tag but are creating a new declaration anyway (because it has attributes or changes the visibility of the name), don't warn that it won't be visible outside the current scope. That's not true. Also narrow down the set of cases where we create these extra declarations when building modules; previously, all tag declarations but the first in a module header would get this treatment if -fmodules-local-submodule-visibility. (This isn't a functional change, but we try to avoid creating these extra declarations whenever we can.) llvm-svn: 257403
* [modules] If we're treating an elaborated-type-specifier as if it introduces aRichard Smith2016-01-091-2/+5
| | | | | | | | tag (because the previous declaration was found in a different module), inject the tag into the appropriate scope (that is, the enclosing scope if we're in a function prototype scope in C++). llvm-svn: 257251
* Module debugging: Add a testcase for standalone forward declarations.Adrian Prantl2016-01-092-0/+6
| | | | llvm-svn: 257241
* [modules] Make sure we always include the contents of private headers whenRichard Smith2016-01-083-3/+5
| | | | | | | | | | building a module. Prior to this change, the private header's content would only be included if the header were included by another header in the same module. If not (if the private header is only used by the .cc files of the module, or is included from outside the module via -Wno-private-header), a #include of that file would be silently ignored. llvm-svn: 257222
* Fix a typo.Adrian Prantl2016-01-061-1/+1
| | | | llvm-svn: 256963
* Module debugging: Defer emitting tag types until their definitionAdrian Prantl2016-01-062-6/+20
| | | | | | | | | was visited and all decls have been merged. We only get a single chance to emit the types for virtual classes because CGDebugInfo::completeRequiredType() categorically doesn't complete them. llvm-svn: 256962
* [modules] When a tag type that was imported from a module is referenced via anRichard Smith2016-01-061-0/+22
| | | | | | | elaborated-type-specifier, create a declaration of it to track that the current module makes it visible too. llvm-svn: 256907
* Fix a typo in testcase and increase its coverage!Adrian Prantl2016-01-051-1/+1
| | | | llvm-svn: 256874
* [modules] Don't try to use the definition of a class ifRichard Smith2015-12-183-4/+20
| | | | | | | RequireCompleteType(..., 0) says we're not permitted to do so. The definition might not be visible, even though we know what it is. llvm-svn: 256045
* Allow non-defining declarations of class template partial specializations toRichard Smith2015-12-111-0/+7
| | | | | | | | | have a nested name specifier. Strictly speaking, forward declarations of class template partial specializations are not permitted at all, but that seems like an obvious wording defect, and if we allow them without a nested name specifier we should also allow them with a nested name specifier. llvm-svn: 255383
* Reapply "[Modules] Fix regression when an elaborated-type-specifier mentions ↵Ben Langmuir2015-12-113-0/+28
| | | | | | | | | a hidden tag" Now not trying to use a C++ lookup mechanism in C (d'oh). Unqualified lookup is actually fine for this case in C. llvm-svn: 255377
* Revert "[Modules] Fix regression when an elaborated-type-specifier mentions ↵Ben Langmuir2015-12-113-28/+0
| | | | | | | | | | a hidden tag" This is causing assertion failures; reverting until I can fix. This reverts commit r255267 llvm-svn: 255324
* [Modules] Fix regression when an elaborated-type-specifier mentions a hidden tagBen Langmuir2015-12-103-0/+28
| | | | | | | | | This makes non-C++ languages find the same decl as C++ does to workaround a regression introduced in r252960. rdar://problem/23784203 llvm-svn: 255267
* [modules] Don't reject multiple modules providing contents for the same ↵Richard Smith2015-12-011-0/+15
| | | | | | embedded file. llvm-svn: 254365
* [modules] Add -cc1 flag -fmodules-embed-all-files.Richard Smith2015-11-241-1/+6
| | | | | | | | | | | | | | This flag causes all files that were read by the compilation to be embedded into a produced module file. This is useful for distributed build systems that use an include scanning system to determine which files are "needed" by a compilation, and only provide those files to remote compilation workers. Since using a module can require any file that is part of that module (or anything it transitively includes), files that are not found by an include scanner can be required in a regular build using explicit modules. With this flag, only files that are actually referenced by transitively-#included files are required to be present on the build machine. llvm-svn: 253950
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-191-2/+2
| | | | | | | | | | This reverts commit r253512. This likely broke the bots in: http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253542
* Change memcpy/memset/memmove to have dest and source alignments.Pete Cooper2015-11-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | This is a follow on from a similar LLVM commit: r253511. Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html These intrinsics currently have an explicit alignment argument which is required to be a constant integer. It represents the alignment of the source and dest, and so must be the minimum of those. This change allows source and dest to each have their own alignments by using the alignment attribute on their arguments. The alignment argument itself is removed. The only code change to clang is hidden in CGBuilder.h which now passes both dest and source alignment to IRBuilder, instead of taking the minimum of dest and source alignments. Reviewed by Hal Finkel. llvm-svn: 253512
* [modules] When a #include is mapped to a module import and appears somewhereRichard Smith2015-11-171-1/+13
| | | | | | | | | | | | | | other than the top level, we issue an error. This breaks a fair amount of C++ code wrapping C libraries, where the C library is #included within a namespace / extern "C" combination, because the C library (probably) includes C++ standard library headers which may be within modules. Without modules, this setup is harmless if (and *only* if) the corresponding standard library module was already included outside the namespace, so downgrade the error to a default-error extension in that case, so that it can be selectively disabled for such misbehaving libraries. llvm-svn: 253398
* [modules] Fix some more cases where we used to reject a conflict between twoRichard Smith2015-11-172-0/+31
| | | | | | | declarations that are not simultaneously visible, and where at least one of them has internal/no linkage. llvm-svn: 253283
* [modules] Allow "redefinition" of typedef of anon tag from unimported submoduleBen Langmuir2015-11-144-0/+17
| | | | | | | | | r233345 started being stricter about typedef names for linkage purposes in non-visible modules, but broke languages without the ODR. rdar://23527954 llvm-svn: 253123
* Fix auto-link for text-based dynamic library SDKs.Juergen Ributzka2015-11-133-0/+19
| | | | | | | | | | When linking against text-based dynamic library SDKs the library name of a framework has now more than one possible filename extensions. This fix tests for both possible extensions (none, and .tbd). This fixes rdar://problem/20609975 llvm-svn: 253060
* [modules] When a declaration has non-trivial visibility, check whether it'sRichard Smith2015-11-131-0/+7
| | | | | | | actually hidden before we check its linkage. This avoids computing the linkage "too early" for an anonymous struct with a typedef name for linkage. llvm-svn: 253012
* [modules] Follow the C++ standard's rule for linkage of enumerators: they haveRichard Smith2015-11-133-5/+8
| | | | | | | | | the linkage of the enumeration. For enumerators of unnamed enumerations, extend the -Wmodules-ambiguous-internal-linkage extension to allow selecting an arbitrary enumerator (but only if they all have the same value, otherwise it's ambiguous). llvm-svn: 253010
* Avoid duplicated diagnostic when lookup for a nested-name-specifier fails ↵Richard Smith2015-11-121-1/+1
| | | | | | due to ambiguity. llvm-svn: 252967
* [modules] Simplify and generalize the existing rule for finding hiddenRichard Smith2015-11-129-21/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | declarations in redeclaration lookup. A declaration is now visible to lookup if: * It is visible (not in a module, or in an imported module), or * We're doing redeclaration lookup and it's externally-visible, or * We're doing typo correction and looking for unimported decls. We now support multiple modules having different internal-linkage or no-linkage definitions of the same name for all entities, not just for functions, variables, and some typedefs. As previously, if multiple such entities are visible, any attempt to use them will result in an ambiguity error. This patch fixes the linkage calculation for a number of entities where we previously didn't need to get it right (using-declarations, namespace aliases, and so on). It also classifies enumerators as always having no linkage, which is a slight deviation from the C++ standard's definition, but not an observable change outside modules (this change is being discussed on the -core reflector currently). This also removes the prior special case for tag lookup, which made some cases of this work, but also led to bizarre, bogus "must use 'struct' to refer to type 'Foo' in this scope" diagnostics in C++. llvm-svn: 252960
* Revert r240335.Richard Smith2015-11-122-3/+6
| | | | | | | | | | | | | | | This failed to solve the problem it was aimed at, and introduced just as many issues as it resolved. Realistically, we need to deal with the possibility that multiple modules might define different internal linkage symbols with the same name, and this isn't a problem unless two such symbols are simultaneously visible. The case where two modules define equivalent internal linkage symbols is handled by r252063: if lookup finds multiple sufficiently-similar entities from different modules, we just pick one of them as an extension (but we keep them separate). llvm-svn: 252957
* Allow use of private headers in different sub-modules.Manuel Klimek2015-11-053-0/+53
| | | | llvm-svn: 252170
* [modules] Don't merge an anonymous enum definition into a named enum definition.Richard Smith2015-11-051-1/+16
| | | | llvm-svn: 252125
* [modules] If we're given a module file, via -fmodule-file=, for a module, butRichard Smith2015-11-051-0/+4
| | | | | | | | | we can't load that file due to a configuration mismatch, and implicit module building is disabled, and the user turns off the error-by-default warning for that situation, then fall back to textual inclusion for the module rather than giving an error if any of its headers are included. llvm-svn: 252114
* [modules] Generalize the workaround for multiple ambiguous definitions ofRichard Smith2015-11-043-1/+9
| | | | | | | | | | | | | internal linkage entities in different modules from r250884 to apply to all names, not just function names. This is really awkward: we don't want to merge internal-linkage symbols from separate modules, because they might not actually be defining the same entity. But we don't want to reject programs that use such an ambiguous symbol if those internal-linkage symbols are in fact equivalent. For now, we're resolving the ambiguity by picking one of the equivalent definitions as an extension. llvm-svn: 252063
* Introduce module file extensions to piggy-back data onto module files.Douglas Gregor2015-11-033-0/+49
| | | | | | | | | | | | | | | | | | | | | Introduce the notion of a module file extension, which introduces additional information into a module file at the time it is built that can then be queried when the module file is read. Module file extensions are identified by a block name (which must be unique to the extension) and can write any bitstream records into their own extension block within the module file. When a module file is loaded, any extension blocks are matched up with module file extension readers, that are per-module-file and are given access to the input bitstream. Note that module file extensions can only be introduced by programmatic clients that have access to the CompilerInvocation. There is only one such extension at the moment, which is used for testing the module file extension harness. As a future direction, one could imagine allowing the plugin mechanism to introduce new module file extensions. llvm-svn: 251955
* [modules] Rationalize the behavior of Decl::declarationReplaces, and inRichard Smith2015-11-036-0/+30
| | | | | | | | | particular don't assume that two declarations of the same kind in the same context are declaring the same entity. That's not true when the same name is declared multiple times as internal-linkage symbols within a module. (getCanonicalDecl is cheap now, so we can just use it here.) llvm-svn: 251898
* Stop back-patching 'readonly' Objective-C properties with 'readwrite' ones.Douglas Gregor2015-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A 'readonly' Objective-C property declared in the primary class can effectively be shadowed by a 'readwrite' property declared within an extension of that class, so long as the types and attributes of the two property declarations are compatible. Previously, this functionality was implemented by back-patching the original 'readonly' property to make it 'readwrite', destroying source information and causing some hideously redundant, incorrect code. Simplify the implementation to express how this should actually be modeled: as a separate property declaration in the extension that shadows (via the name lookup rules) the declaration in the primary class. While here, correct some broken Fix-Its, eliminate a pile of redundant code, clean up the ARC migrator's handling of properties declared in extensions, and fix debug info's naming of methods that come from categories. A wonderous side effect of doing this write is that it eliminates the "AddedObjCPropertyInClassExtension" method from the AST mutation listener, which in turn eliminates the last place where we rewrite entire declarations in a chained PCH file or a module file. This change (which fixes rdar://problem/18475765) will allow us to eliminate the rewritten-decls logic from the serialization library, and fixes a crash (rdar://problem/23247794) illustrated by the test/PCH/chain-categories.m example. llvm-svn: 251874
* Support watchOS and tvOS driver optionsTim Northover2015-10-301-0/+0
| | | | | | | | This patch should add support for almost all command-line options and driver tinkering necessary to produce a correct "clang -cc1" invocation for watchOS and tvOS. llvm-svn: 251706
* Fix missing builtin identifier infos with PCH+modulesBen Langmuir2015-10-283-0/+11
| | | | | | | | | | | | | | Use the *current* state of "is-moduleness" rather than the state at serialization time so that if we read a builtin identifier from a module that wasn't "interesting" to that module, we will still write it out to a PCH that imports that module. Otherwise, we would get mysterious "unknown builtin" errors when using PCH+modules. rdar://problem/23287656 llvm-svn: 251565
* Fixup this testcase after r251120.Adrian Prantl2015-10-231-3/+5
| | | | | | I accidentally tested r251120 with assertions disabled. llvm-svn: 251126
* Module Debugging: Emit module debug info for types inside of Objective-CAdrian Prantl2015-10-233-0/+15
| | | | | | | | containers. rdar://problem/23196170 llvm-svn: 251120
* [modules] libstdc++ defines some static inline functions in its internalRichard Smith2015-10-216-0/+28
| | | | | | | | | | | headers. If those headers end up being textually included twice into the same module, we get ambiguity errors. Work around this by downgrading the ambiguity error to a warning if multiple identical internal-linkage functions appear in an overload set, and just pick one of those functions as the lookup result. llvm-svn: 250884
* [modules] Allow the error when explicitly loading an incompatible module fileRichard Smith2015-10-161-3/+2
| | | | | | | | | via -fmodule-file= to be turned off; in that case, just include the relevant files textually. This allows module files to be unconditionally passed to all compile actions via CXXFLAGS, and to be ignored for rules that specify custom incompatible flags. llvm-svn: 250577
* [modules] Allow the error on importing a C++ module within an extern "C"Richard Smith2015-10-131-6/+8
| | | | | | | | | context (but otherwise at the top level) to be disabled, to support use of C++ standard library implementations that (legitimately) mark their <blah.h> headers as being C++ headers from C libraries that wrap things in 'extern "C"' a bit too enthusiastically. llvm-svn: 250137
* [modules] Fix merging of __va_list_tag's implicit special member functions.Richard Smith2015-10-135-0/+26
| | | | | | | | | | | We model predefined declarations as not being from AST files, but in most ways they act as if they come from some implicit prebuilt module file imported before all others. Therefore, if we see an update to the predefined 'struct __va_list_tag' declaration (and we've already loaded any modules), it needs a corresponding update record, even though it didn't technically come from an AST file. llvm-svn: 250134
* Update tests touched by r249656David Majnemer2015-10-081-1/+1
| | | | | | | | | These test updates almost exclusively around the change in behavior around enum: enums without a definition are considered incomplete except when targeting MSVC ABIs. Since these tests are interested in the 'incomplete-enum' behavior, restrict them to %itanium_abi_triple. llvm-svn: 249660
* Stop messing with the 'g' group of options in CompilerInvocation.Douglas Katzman2015-10-088-12/+12
| | | | | | | | | | | | | | | | With this change, most 'g' options are rejected by CompilerInvocation. They remain only as Driver options. The new way to request debug info from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}" and "-dwarf-version={2|3|4}". In the absence of a command-line option to specify Dwarf version, the Toolchain decides it, rather than placing Toolchain-specific logic in CompilerInvocation. Also fix a bug in the Windows compatibility argument parsing in which the "rightmost argument wins" principle failed. Differential Revision: http://reviews.llvm.org/D13221 llvm-svn: 249655
OpenPOWER on IntegriCloud