summaryrefslogtreecommitdiffstats
path: root/clang/test/Modules/Inputs
Commit message (Collapse)AuthorAgeFilesLines
...
* Module Debugging: Fix a crash when emitting debug info for nested tag typesAdrian Prantl2016-03-071-0/+11
| | | | | | | | whose DeclContext is not yet complete by deferring their emission. rdar://problem/24918680 llvm-svn: 262851
* [modules] Prefer more complete array types.Vassil Vassilev2016-02-283-5/+0
| | | | | | | | | | | | | | If we import a module that has a complete array type and one that has an incomplete array type, the declaration found by name lookup might be the one with the incomplete type, possibly resulting in rejects-valid. Now, the name lookup prefers decls with a complete array types. Also, diagnose cases when the redecl chain has array bound, different from the merge candidate. Reviewed by Richard Smith. llvm-svn: 262189
* [modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a singleRichard Smith2016-02-191-1/+1
| | | | | | | | | | | | option. Previously these options could both be used to specify that you were compiling the implementation file of a module, with a different set of minor bugs in each case. This change removes -fmodule-implementation-of, and instead tracks a flag to determine whether we're currently building a module. -fmodule-name now behaves the same way that -fmodule-implementation-of previously did. llvm-svn: 261372
* Don't synthesize an ImportDecl for a module named in -fmodule-implementation-ofBen Langmuir2016-02-051-0/+1
| | | | | | | | | | When building a PCH with modules enabled this import would assert in the ASTWriter and (if assertions were disabled) sometimes crash the compiler that loaded the resulting PCH when trying to lookup the submodule ID. rdar://problem/24137448 llvm-svn: 259859
* Fix predefine for __NSConstantString struct typeBen Langmuir2016-02-041-3/+0
| | | | | | | | | | | | | | | | | Per review feedback the name was wrong and it can be used outside Objective-C. Unfortunately, making the internal struct visible broke some ASTMatchers tests that assumed that the first record decl would be from user code, rather than a builtin type. I'm worried that this will also affect users' code. So this patch adds a typedef to wrap the internal struct and only makes the typedef visible to namelookup. This is sufficient to allow the ASTReader to merge the decls we need without making the struct itself visible. rdar://problem/24425801 llvm-svn: 259734
* Reapply r259624, it is likely not the commit causing the bot failures.Quentin Colombet2016-02-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Original message: Make CF constant string decl visible to name lookup to fix module errors The return type of the __builtin___*StringMakeConstantString functions is a pointer to a struct, so we need that struct to be visible to name lookup so that we will correctly merge multiple declarations of that type if they come from different modules. Incidentally, to make this visible to name lookup we need to rename the type to __NSConstantString, since the real NSConstantString is an Objective-C interface type. This shouldn't affect anyone outside the compiler since users of the constant string builtins cast the result immediately to CFStringRef. Since this struct type is otherwise implicitly created by the AST context and cannot access namelookup, we make this a predefined type and initialize it in Sema. Note: this issue of builtins that refer to types not visible to name lookup technically also affects other builtins (e.g. objc_msgSendSuper), but in all other cases the builtin is a library builtin and the issue goes away if you include the library that defines the types it uses, unlike for these constant string builtins. rdar://problem/24425801 llvm-svn: 259721
* Revert r259624 - Make CF constant string decl visible to name lookup to fix ↵Quentin Colombet2016-02-031-7/+0
| | | | | | | | | module errors. This breaks some internal bots in stage2: clang seg fault. Looking with Ben to see what is going on. llvm-svn: 259715
* Make CF constant string decl visible to name lookup to fix module errorsBen Langmuir2016-02-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | The return type of the __builtin___*StringMakeConstantString functions is a pointer to a struct, so we need that struct to be visible to name lookup so that we will correctly merge multiple declarations of that type if they come from different modules. Incidentally, to make this visible to name lookup we need to rename the type to __NSConstantString, since the real NSConstantString is an Objective-C interface type. This shouldn't affect anyone outside the compiler since users of the constant string builtins cast the result immediately to CFStringRef. Since this struct type is otherwise implicitly created by the AST context and cannot access namelookup, we make this a predefined type and initialize it in Sema. Note: this issue of builtins that refer to types not visible to name lookup technically also affects other builtins (e.g. objc_msgSendSuper), but in all other cases the builtin is a library builtin and the issue goes away if you include the library that defines the types it uses, unlike for these constant string builtins. rdar://problem/24425801 llvm-svn: 259624
* Merge templated static member variables, fixes http://llvm.org/pr26179.Yaron Keren2016-01-224-0/+29
| | | | | | | Patch by Vassil Vassilev! Reviewed by Richard Smith. llvm-svn: 258524
* Module Debugging: Fine-tune the condition that determines whether a typeAdrian Prantl2016-01-201-0/+6
| | | | | | | | | | | | | 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-191-0/+14
| | | | | | rdar://problem/24199640 llvm-svn: 258252
* Module Debugging: Make sure that anonymous tag decls that define globalAdrian Prantl2016-01-191-0/+4
| | | | | | | | | 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-191-0/+4
| | | | | | | | | | | | | 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-123-3/+6
| | | | | | equivalent internal linkage entities. llvm-svn: 257512
* Module debugging: Add a testcase for standalone forward declarations.Adrian Prantl2016-01-091-0/+2
| | | | llvm-svn: 257241
* [modules] Make sure we always include the contents of private headers whenRichard Smith2016-01-081-1/+3
| | | | | | | | | | 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-061-0/+6
| | | | | | | | | 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
* 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-112-0/+10
| | | | | | | | | 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-112-10/+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-102-0/+10
| | | | | | | | | 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] Fix some more cases where we used to reject a conflict between twoRichard Smith2015-11-171-0/+6
| | | | | | | 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-143-0/+9
| | | | | | | | | 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-132-0/+2
| | | | | | | | | | 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] Follow the C++ standard's rule for linkage of enumerators: they haveRichard Smith2015-11-131-1/+0
| | | | | | | | | 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
* [modules] Simplify and generalize the existing rule for finding hiddenRichard Smith2015-11-123-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Allow use of private headers in different sub-modules.Manuel Klimek2015-11-052-0/+18
| | | | llvm-svn: 252170
* [modules] Generalize the workaround for multiple ambiguous definitions ofRichard Smith2015-11-042-0/+2
| | | | | | | | | | | | | 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-032-0/+5
| | | | | | | | | | | | | | | | | | | | | 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-035-0/+18
| | | | | | | | | 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
* Fix missing builtin identifier infos with PCH+modulesBen Langmuir2015-10-282-0/+3
| | | | | | | | | | | | | | 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
* Module Debugging: Emit module debug info for types inside of Objective-CAdrian Prantl2015-10-231-0/+10
| | | | | | | | containers. rdar://problem/23196170 llvm-svn: 251120
* [modules] libstdc++ defines some static inline functions in its internalRichard Smith2015-10-215-0/+21
| | | | | | | | | | | 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] Fix merging of __va_list_tag's implicit special member functions.Richard Smith2015-10-134-0/+18
| | | | | | | | | | | 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
* Module debugging: Don't emit forward declarations in module scopes.Adrian Prantl2015-10-021-0/+1
| | | | | | A forward declaration inside a module header does not belong to the module. llvm-svn: 249157
* Module debugging: Also emit Objective-C interfaces forward declarationsAdrian Prantl2015-10-011-0/+2
| | | | | | in their module scope when building a clang module. llvm-svn: 249031
* Module debugging: Support submodules in the PCM/PCH debug info.Adrian Prantl2015-09-203-0/+17
| | | | llvm-svn: 248127
* [Modules] More descriptive diagnostics for misplaced import directiveSerge Pavlov2015-09-193-0/+14
| | | | | | | | | | If an import directive was put into wrong context, the error message was obscure, complaining on misbalanced braces. To get more descriptive messages, annotation tokens related to modules are processed where they must not be seen. Differential Revision: http://reviews.llvm.org/D11844 llvm-svn: 248085
* [modules] Make sure we make hidden UsingShadowDecls visible to redeclarationRichard Smith2015-09-152-0/+2
| | | | | | lookup for the UsingShadowDecls themselves. llvm-svn: 247714
* [modules] A using-declaration doesn't introduce a new entity, just a new nameRichard Smith2015-09-151-0/+26
| | | | | | | for an existing entity, and as such a using-declaration doesn't need to conflict with a hidden entity (nor vice versa). llvm-svn: 247654
* Add new test file missing from r247486.Richard Smith2015-09-111-0/+6
| | | | llvm-svn: 247488
* [modules] When picking one of two template declarations as a lookup result,Richard Smith2015-09-112-0/+7
| | | | | | | | it's not sufficient to prefer the declaration with more default arguments, or the one that's visible; they might both be visible, but one of them might have a visible default argument where the other has a hidden default argument. llvm-svn: 247486
* Module Debugging: Emit debug type information into clang ObjC modules.Adrian Prantl2015-09-083-5/+15
| | | | | | | | | | When -fmodule-format is set to "obj", emit debug info for all types declared in a module or referenced by a declaration into the module's object file container. This patch adds support for Objective-C types and methods. llvm-svn: 247068
* Module Debugging: Emit debug type information into clang modules.Adrian Prantl2015-09-082-0/+56
| | | | | | | | | | When -fmodule-format is set to "obj", emit debug info for all types declared in a module or referenced by a declaration into the module's object file container. This patch adds support for C and C++ types. llvm-svn: 247049
* [modules] Tests for r245390.Richard Smith2015-08-184-0/+7
| | | | llvm-svn: 245391
* [modules] When parsing the base specifiers of a parse-merged class, the currentRichard Smith2015-08-172-0/+10
| | | | | | | | context is the class itself but lookups should be performed starting with the lookup parent of the class (class and base members don't shadow types from the surrounding context because they have not been declared yet). llvm-svn: 245236
* [modules] PR20507: Avoid silent textual inclusion.Sean Silva2015-08-179-3/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a module was unavailable (either a missing requirement on the module being imported, or a missing file anywhere in the top-level module (and not dominated by an unsatisfied `requires`)), we would silently treat inclusions as textual. This would cause all manner of crazy and confusing errors (and would also silently "work" sometimes, making the problem difficult to track down). I'm really not a fan of the `M->isAvailable(getLangOpts(), getTargetInfo(), Requirement, MissingHeader)` function; it seems to do too many things at once, but for now I've done things in a sort of awkward way. The changes to test/Modules/Inputs/declare-use/module.map were necessitated because the thing that was meant to be tested there (introduced in r197805) was predicated on silently falling back to textual inclusion, which we no longer do. The changes to test/Modules/Inputs/macro-reexport/module.modulemap are just an overlooked missing header that seems to have been missing since this code was committed (r213922), which is now caught. Reviewers: rsmith, benlangmuir, djasper Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10423 llvm-svn: 245228
* [Modules] Add Darwin-specific compatibility module map parsing hacksBen Langmuir2015-08-133-0/+26
| | | | | | | | | | | | | | | | This preserves backwards compatibility for two hacks in the Darwin system module map files: 1. The use of 'requires excluded' to make headers non-modular, which should really be mapped to 'textual' now that we have this feature. 2. Silently removes a bogus cplusplus requirement from IOKit.avc. Once we start diagnosing missing requirements and headers on auto-imports these would have broken compatibility with existing Darwin SDKs. llvm-svn: 244912
* [modules] Fix thread safety analysis to cope with merging of FieldDecls ↵Richard Smith2015-08-124-0/+25
| | | | | | across modules. llvm-svn: 244714
OpenPOWER on IntegriCloud