summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules
Commit message (Collapse)AuthorAgeFilesLines
...
* C++ modules: fix a bug where loading a declaration with some name would preventRichard Smith2013-09-095-5/+27
| | | | | | | | | | | | | | | | | name lookup from lazily deserializing the other declarations with the same name, by tracking a bit to indicate whether a name in a DeclContext might have additional external results. This also allows lazier reconciling of the lookup table if a module import adds decls to a pre-existing DC. However, this exposes a pre-existing bug, which causes a regression in test/Modules/decldef.mm: if we have a reference to a declaration, and a later-imported module adds a redeclaration, nothing causes us to load that redeclaration when we use or emit the reference (which can manifest as a reference to an undefined inline function, a use of an incomplete type, and so on). decldef.mm has been extended with an additional testcase which fails with or without this change. llvm-svn: 190293
* Note when a decl is used in AST files.Eli Friedman2013-09-053-1/+11
| | | | | | | | | | | | | | | When an AST file is built based on another AST file, it can use a decl from the fist file, and therefore mark the "isUsed" bit. We need to note this in the AST file so that the bit is set correctly when the second AST file is loaded. This patch introduces the distinction between setIsUsed() and markUsed() so that we don't call into the ASTMutationListener callback when it wouldn't be appropriate. Fixes PR16635. llvm-svn: 190016
* Map from local decl IDs to global decl IDs when lazily deserializing friend ↵Richard Smith2013-08-304-0/+21
| | | | | | decl chains. llvm-svn: 189629
* During typo correction, check for an exact match in an unimported module. If weRichard Smith2013-08-206-20/+44
| | | | | | find one, then report the error as a missing import instead of as a typo. llvm-svn: 188821
* Fix FileCheck --check-prefix lines.Tim Northover2013-08-121-2/+2
| | | | | | | | | | Various tests had sprung up over the years which had --check-prefix=ABC on the RUN line, but "CHECK-ABC:" later on. This happened to work before, but was strictly incorrect. FileCheck is getting stricter soon though. Patch by Ron Ofir. llvm-svn: 188174
* When merging redeclaration chains across modules, if a declaration is visibleRichard Smith2013-08-023-0/+12
| | | | | | | | | | | | | | | | | | | in one module but is only declared as a friend in another module, keep it visible in the result of the merge. This is incomplete on two axes: 1) Our handling of local extern declarations is basically broken (we put them in the wrong decl context, and don't find them in redeclaration lookup, unless they've previously been declared), and this results in them making friends visible after a merge. 2) Eventually we'll need to mark that this has happened, and more carefully check whether a declaration should be visible if it was only visible in some of the modules in which it was declared. Fortunately it's rare for the identifier namespace of a declaration to change along its redeclaration chain. llvm-svn: 187639
* Fix assert when instantiating a default argument of a template defined in aRichard Smith2013-08-012-0/+5
| | | | | | module. llvm-svn: 187556
* When we perform dependent name lookup during template instantiation, it's notRichard Smith2013-07-256-5/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sufficient to only consider names visible at the point of instantiation, because that may not include names that were visible when the template was defined. More generally, if the instantiation backtrace goes through a module M, then every declaration visible within M should be available to the instantiation. Any of those declarations might be part of the interface that M intended to export to a template that it instantiates. The fix here has two parts: 1) If we find a non-visible declaration during name lookup during template instantiation, check whether the declaration was visible from the defining module of all entities on the active template instantiation stack. The defining module is not the owning module in all cases: we look at the module in which a template was defined, not the module in which it was first instantiated. 2) Perform pending instantiations at the end of a module, not at the end of the translation unit. This is general goodness, since it significantly cuts down the amount of redundant work that is performed in every TU importing a module, and also implicitly adds the module containing the point of instantiation to the set of modules checked for declarations in a lookup within a template instantiation. There's a known issue here with template instantiations performed while building a module, if additional imports are added later on. I'll fix that in a subsequent commit. llvm-svn: 187167
* If an unimported submodule of an imported module contains a declaration of aRichard Smith2013-07-144-0/+22
| | | | | | | global allocation or deallocation function, that should not cause that global allocation or deallocation function to become unavailable. llvm-svn: 186270
* Add 'not' to commands that are expected to fail.Rafael Espindola2013-07-047-10/+10
| | | | | | | This is at least good documentation, but also opens the possibility of using pipefail. llvm-svn: 185652
* Fix deserializing of class template partial specializations. Assign sequenceRichard Smith2013-06-255-12/+36
| | | | | | | | | | numbers as we deserialize class template partial specializations. We can't assume that the old sequence numbers will work. The sequence numbers are still deterministic, but are now a lot less predictable for class template partial specializations in modules/PCH. llvm-svn: 184811
* Check for matching template-parameter-lists when merging template declarations.Richard Smith2013-06-243-0/+34
| | | | llvm-svn: 184791
* Avoid adding entries to the DeclContext lookup table multiple times when lazilyRichard Smith2013-06-241-4/+0
| | | | | | | | | | | | | | | | | constructing a lookup table. Previously, buildLookup would add lookup table entries for each item lexically within the DC, and adding the first entry with a given name would trigger the external source to add all its entries with that name. Then buildLookup would carry on and re-add those entries all over again. Instead, follow a simple rule: a declaration from an external source is only ever made visible by the external source. One exception to this: since we don't usually build a lookup table for the TU in C, and we never serialize one, we don't expect the external source to provide lookups in the TU in C, so we build those ones ourselves. llvm-svn: 184696
* Slightly improve cross-module merging for function templates.Richard Smith2013-06-244-0/+61
| | | | llvm-svn: 184689
* [Modules] If a module map resides in a system header directory, treat it as ↵Douglas Gregor2013-06-213-0/+13
| | | | | | | | | a system module. This prevents -pedantic from causing warnings in the system headers used to create modules. Fixes <rdar://problem/14201171>. llvm-svn: 184560
* Add test header missing from r184504.Douglas Gregor2013-06-211-0/+3
| | | | llvm-svn: 184505
* When building a module, keep *all* declared methods in the global method pool.Douglas Gregor2013-06-213-0/+9
| | | | | | | | | | | | | | | | | As an optimization, we only kept declared methods with distinct signatures in the global method pool, to keep the method lists small. Under modules, however, one could have two different methods with the same signature that occur in different (sub)modules. If only the later submodule is important, message sends to 'id' with that selector would fail because the first method (the only one that got into the method pool) was hidden. When building a module, keep *all* of the declared methods. I did a quick check of both module build time and uses of modules, and found no performance regression despite this causing us to keep more methods in the global method pool. Fixes <rdar://problem/14148896>. llvm-svn: 184504
* Test files for private header patch.Lawrence Crowl2013-06-2015-0/+127
| | | | llvm-svn: 184472
* Suffixing #pragma comment(lib) library names with .lib if necessary. This ↵Aaron Ballman2013-05-241-1/+1
| | | | | | matches MSVC behavior, as well as allows us to properly link libraries such as the ones provided by the MSDN examples. llvm-svn: 182647
* User correct case for 'FileCheck'.Argyrios Kyrtzidis2013-05-241-1/+1
| | | | llvm-svn: 182632
* [modules] If we hit a failure while loading a PCH/module, abort parsing ↵Argyrios Kyrtzidis2013-05-241-0/+26
| | | | | | | | | | instead of trying to continue in an invalid state. Also don't let libclang create a PCH with such an error. Fixes rdar://13953768 llvm-svn: 182629
* Add arm_neon.h to the builtin intrinsics module map.Douglas Gregor2013-05-201-0/+6
| | | | | | Fixes <rdar://problem/13933913>. llvm-svn: 182268
* Fix broken testDouglas Gregor2013-05-201-1/+1
| | | | llvm-svn: 182264
* Add -Wincomplete-module, which detects when a header is included from a ↵Douglas Gregor2013-05-204-0/+12
| | | | | | module but isn't itself part of a module. llvm-svn: 182263
* clang/test/Modules/self-import-header/test.m: Add explicit -target.NAKAMURA Takumi2013-05-161-0/+1
| | | | | | | | Clang has an issue between mingw/include/float.h and clang/Headers/float.h with cyclic include_next. For now, it should work to suppress #include_next in clang/float.h with an explicit target. (It may work with -U__MINGW32__, though.) llvm-svn: 181988
* improve of note message and minor refactoring of my lastFariborz Jahanian2013-05-151-1/+1
| | | | | | patch (r181847). llvm-svn: 181896
* Objective-C [diagnostics] [QOI], when method is notFariborz Jahanian2013-05-141-0/+1
| | | | | | | | found for a receiver, note where receiver class is declaraed (this is most common when receiver is a forward class). // rdar://3258331 llvm-svn: 181847
* [modules] When building a module, make sure we don't serialize out ↵Argyrios Kyrtzidis2013-05-086-0/+22
| | | | | | | | | | | HeaderFileInfo for headers not belonging to the module. After r180934 we may initiate module map parsing for modules not related to the module what we are building, make sure we ignore the header file info of headers from such modules. First part of rdar://13840148 llvm-svn: 181489
* Forward #pragma comment(lib/linker) through as flags metadataReid Kleckner2013-05-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Most of this change is wiring the pragma all the way through from the lexer, parser, and sema to codegen. I considered adding a Decl AST node for this, but it seemed too heavyweight. Mach-O already uses a metadata flag called "Linker Options" to do this kind of auto-linking. This change follows that pattern. LLVM knows how to forward the "Linker Options" metadata into the COFF .drectve section where these flags belong. ELF support is not implemented, but possible. This is related to auto-linking, which is http://llvm.org/PR13016. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D723 llvm-svn: 181426
* Remove forward slashes from check; should unbreak Windows buildbots.Douglas Gregor2013-05-061-1/+1
| | | | llvm-svn: 181199
* When building a module, forward diagnostics to the outer diagnostic consumer.Douglas Gregor2013-05-035-2/+46
| | | | | | | | | | | | | | | Previously, we would clone the current diagnostic consumer to produce a new diagnostic consumer to use when building a module. The problem here is that we end up losing diagnostics for important diagnostic consumers, such as serialized diagnostics (where we'd end up with two diagnostic consumers writing the same output file). With forwarding, the diagnostics from all of the different modules being built get forwarded to the one serialized-diagnostic consumer and are emitted in a sane way. Fixes <rdar://problem/13663996>. llvm-svn: 181067
* When looking for the module associated with one of our magical builtin ↵Douglas Gregor2013-05-024-3/+19
| | | | | | | | | | | | | | | headers, speculatively load module maps. The "magical" builtin headers are the headers we provide as part of the C standard library, which typically comes from /usr/include. We essentially merge our headers into that location (due to cyclic dependencies). This change makes sure that, when header search finds one of our builtin headers, we figure out which module it actually lives in. This case is fairly rare; one ends up having to include one of the few built-in C headers we provide before including anything from /usr/include to trigger it. Fixes <rdar://problem/13787184>. llvm-svn: 180934
* [Modules] Fix an issue where the reconstructed redeclaration chain was ↵Argyrios Kyrtzidis2013-04-264-0/+33
| | | | | | | | | | | | | incomplete, missing the definition from a module. -Make sure that a deserialized external decl gets added to the TU scope. -When associating an identifier with a set of decls, use the most recent local ones, if they exist, otherwise associating decls from modules (that came after a local one) will lead to an incomplete reconstructed re-declaration chain. rdar://13712705 llvm-svn: 180634
* Avoid names like __in that conflict with SAL in builtin headersReid Kleckner2013-04-191-1/+0
| | | | | | | | | | | | | | Microsoft's Source Annotation Language (SAL) defines a bunch of keywords for annotating the inputs and outputs of functions. Empty definitions for the keywords are provided by <stdlib.h> -> <crtdefs.h> -> <sal.h>. This makes it basically impossible to include MSVC's stdlib.h and Clang's *mmintrin.h headers at the same time if they have variables named __in. As a workaround, I've renamed those variables. This fixes the Modules/compiler_builtins.m test which was XFAILed, presumably due to this conflict. llvm-svn: 179860
* Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.Andy Gibbs2013-04-1718-94/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VerifyDiagnosticConsumer previously would not check that the diagnostic and its matching directive referenced the same source file. Common practice was to create directives that referenced other files but only by line number, and this led to problems such as when the file containing the directive didn't have enough lines to match the location of the diagnostic in the other file, leading to bizarre file formatting and other oddities. This patch causes VerifyDiagnosticConsumer to match source files as well as line numbers. Therefore, a new syntax is made available for directives, for example: // expected-error@file:line {{diagnostic message}} This extends the @line feature where "file" is the file where the diagnostic is generated. The @line syntax is still available and uses the current file for the diagnostic. "file" can be specified either as a relative or absolute path - although the latter has less usefulness, I think! The #include search paths will be used to locate the file and if it is not found an error will be generated. The new check is not optional: if the directive is in a different file to the diagnostic, the file must be specified. Therefore, a number of test-cases have been updated with regard to this. This closes out PR15613. llvm-svn: 179677
* [Modules] Convert module specific -fno-modules-autolink into -fno-autolink.Daniel Dunbar2013-04-161-1/+5
| | | | | | | | | - There is no reason to have a modules specific flag for disabling autolinking. Instead, convert the existing flag into -fno-autolink (which should cover other autolinking code generation paths like #pragmas if and when we support them). llvm-svn: 179612
* Make sure we have the include paths we needDouglas Gregor2013-04-121-3/+3
| | | | llvm-svn: 179347
* <rdar://problem/13615607> Include SDK version information in the module hash.Douglas Gregor2013-04-121-0/+32
| | | | | | | | | This is a Darwin-SDK-specific hash criteria used to identify a particular SDK without having to hash the contents of all of its headers. If other platforms have such versioned files, we should add those checks here. llvm-svn: 179346
* Add a module testcase with a using declaration.Rafael Espindola2013-04-053-2/+12
| | | | | | Thanks a lot to Richard Smith for the suggestion. llvm-svn: 178825
* Add hasExternalLinkageUncached back with the test that Richard provided, butRafael Espindola2013-04-044-0/+18
| | | | | | keep the call at the current location. llvm-svn: 178741
* <rdar://problem/13560075> Teach name lookup for builtin names to find hidden ↵Douglas Gregor2013-04-034-0/+30
| | | | | | | | | | | | | | declarations. Normal name lookup ignores any hidden declarations. When name lookup for builtin declarations fails, we just synthesize a new declaration at the point of use. With modules, this could lead to multiple declarations of the same builtin, if one came from a (hidden) submodule that was later made visible. Teach name lookup to always find builtin names, so we don't create these redundant declarations in the first place. llvm-svn: 178711
* [preprocessor] Allow comparing two macro definitions syntactically instead ↵Argyrios Kyrtzidis2013-04-033-0/+5
| | | | | | | | | | | | | | of only lexically. Syntactically means the function macro parameter names do not need to use the same identifiers in order for the definitions to be considered identical. Syntactic equivalence is a microsoft extension for macro redefinitions and we'll also use this kind of comparison to check for ambiguous macros coming from modules. rdar://13562254 llvm-svn: 178671
* [modules] If a submodule has re-definitions of the same macro, only the last ↵Argyrios Kyrtzidis2013-04-031-2/+2
| | | | | | | | definition will be used as the "exported" one. Fixes rdar://13562262 llvm-svn: 178622
* [modules] Make sure enabled diagnostic pragmas inside the module don't ↵Argyrios Kyrtzidis2013-03-273-0/+20
| | | | | | | | | | | | affect the translation unit that imports the module. Getting diagnostic sections from modules properly working is a fixme. rdar://13516663 llvm-svn: 178151
* <rdar://problem/13509689> Introduce -module-file-info option that provides ↵Douglas Gregor2013-03-271-0/+34
| | | | | | | | | | | information about a particular module file. This option can be useful for end users who want to know why they ended up with a ton of different variants of the "std" module in their module cache. This problem should go away over time, as we reduce the need for module variants, but it will never go away entirely. llvm-svn: 178148
* [modules] Re-enable the "ambiguous expansion of macro" warning.Argyrios Kyrtzidis2013-03-271-14/+14
| | | | | | | | | | Also update "test/Modules/macros.c" to test modified semantics: -When there is an ambiguous macro, expand using the latest introduced version, not the first one. -#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause undefining of macros in the translation unit that imported that submodule. This reduces macro namespace interference across modules. llvm-svn: 178105
* Remove local path from test.Douglas Gregor2013-03-251-2/+2
| | | | llvm-svn: 177925
* Use xargs rather than Douglas Gregor2013-03-251-2/+2
| | | | llvm-svn: 177923
* Use 'touch -t', which both BSD and Linux support.Douglas Gregor2013-03-251-4/+4
| | | | llvm-svn: 177921
* <rdar://problem/13434605> Periodically prune the module cache so that it ↵Douglas Gregor2013-03-251-0/+46
| | | | | | does not grow forever. llvm-svn: 177918
OpenPOWER on IntegriCloud