summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/DeclBase.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-081-12/+27
| | | | | | minor fixes (NFC). llvm-svn: 317644
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-101-3/+2
| | | | | | | | | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. This reinstates r315251 and r315256, reverted in r315309 and r315308 respectively, tweaked to avoid triggering a linkage calculation when declaring implicit special members (this exposed our pre-existing issue with typedef names for linkage changing the linkage of types whose linkage has already been computed and cached in more cases). A testcase for that regression has been added in r315366. llvm-svn: 315379
* Revert "[Modules TS] Module ownership semantics for redeclarations."Eric Liu2017-10-101-2/+3
| | | | | | This reverts commit r315251. See the original commit thread for reason. llvm-svn: 315309
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-091-3/+2
| | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. llvm-svn: 315251
* Add IDNS_Tag to C++ declarations that conflict with tag declarations.Richard Smith2017-09-071-6/+5
| | | | | | | Fixes some accepts-invalids with tags and other declarations declared in the same scope. llvm-svn: 312743
* Always allocate room for a ModuleDecl on the TranslationUnitDecl.Richard Smith2017-09-051-2/+3
| | | | | | Sometimes we create the ASTContext and thus the TranslationUnitDecl before we know the LangOptions. This should fix the asan buildbot failures after r312467. llvm-svn: 312506
* [modules ts] Improve merging of module-private declarations.Richard Smith2017-07-051-2/+4
| | | | | | | | | | These cases occur frequently for declarations in the global module (above the module-declaration) in a Modules TS module interface. When we merge a definition from another module into such a module-private definition, ensure that we transitively make everything lexically within that definition visible to that translation unit. llvm-svn: 307129
* [modules ts] Declarations from a module interface unit are only visible outsideRichard Smith2017-07-051-1/+1
| | | | | | the module if declared in an export block. llvm-svn: 307115
* PR33552: Distinguish between declarations that are owned by no module andRichard Smith2017-06-231-3/+3
| | | | | | | | | | | | | | | | | | | declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
* D31187: Fix removal of out-of-line definitions.Vassil Vassilev2017-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | Consider: struct MyClass { void f() {} } MyClass::f(){} // expected error redefinition of f. #1 Some clients (eg. cling) need to call removeDecl for the redefined (#1) decl. This patch enables us to remove the lookup entry is registered in the semantic decl context and not in the primary decl context of the lexical decl context where we currently are trying to remove it from. It is not trivial to test this piece and writing a full-blown unit test seems too much. llvm-svn: 305799
* Make helper functions static. NFC.Benjamin Kramer2017-05-261-2/+2
| | | | llvm-svn: 304028
* [modules] When reparenting a local declaration, don't mark the declaration asRichard Smith2017-05-231-3/+11
| | | | | | | | | | | being visible with its owning module if we're not tracking owning modules for local declarations. This avoids the possibility of a declaration being (meaninglessly) marked as hidden with no owning module, which would otherwise lead to violated AST invariants (checked by the added assertion). llvm-svn: 303699
* [index] Fix forward declarations interfering with USR generation of external ↵Argyrios Kyrtzidis2017-05-201-0/+21
| | | | | | | | | source symbols Patch by Nathan Hawes. https://reviews.llvm.org/D33346 llvm-svn: 303484
* [modules] When creating a declaration, cache its owning module immediatelyRichard Smith2017-05-171-3/+7
| | | | | | | | | | | | | | | rather than waiting until it's queried. Currently this is only applied to local submodule visibility mode, as we don't yet allocate storage for the owning module in non-local-visibility modules compilations. This reinstates r302965, reverted in r303037, with a fix for the reported crash, which occurred when reparenting a local declaration to be a child of a hidden imported declaration (specifically during template instantiation). llvm-svn: 303224
* Revert r302965 - [modules] When creating a declaration, cache its owningDaniel Jasper2017-05-151-10/+3
| | | | | | | | | module immediately Also revert dependent r302969. This is leading to crashes. Will provide more details reproduction instructions to Richard. llvm-svn: 303037
* Add LangOptions method to query whether we are tracking the owning module ↵Richard Smith2017-05-131-2/+2
| | | | | | | | for a local declaration. In preparation for expanding this behavior to cover additional cases. llvm-svn: 302969
* [modules] When creating a declaration, cache its owning module immediatelyRichard Smith2017-05-121-1/+8
| | | | | | | | | | rather than waiting until it's queried. Currently this is only applied to local submodule visibility mode, as we don't yet allocate storage for the owning module in non-local-visibility modules compilations. llvm-svn: 302965
* [ObjC] Disallow vector parameters and return values in Objective-C methodsAlex Lorenz2017-04-271-10/+28
| | | | | | | | | | | | | | | | | for iOS < 9 and OS X < 10.11 X86 targets This commit adds a new error that disallows methods that have parameters/return values with a vector type for some older X86 targets. This diagnostic is needed because objc_msgSend doesn't support SIMD vector registers/return values on X86 in iOS < 9 and OS X < 10.11. Note that we don't necessarily know if the vector argument/return value will use a SIMD register, so instead we chose to be conservative and prohibit all vector types. rdar://21662309 Differential Revision: https://reviews.llvm.org/D28670 llvm-svn: 301532
* Revert "Address http://bugs.llvm.org/pr30994 so that a non-friend can ↵Benjamin Kramer2017-04-171-15/+0
| | | | | | | | | properly replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp." This reverts commit r300443. Breaks compiling libc++ with modules in some configurations. llvm-svn: 300497
* Address http://bugs.llvm.org/pr30994 so that a non-friend can properly ↵Yaron Keren2017-04-171-0/+15
| | | | | | | | | | | | replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp. The code implements Richard Smith suggestion in comment 3 of the PR. reviewer: Vassil Vassilev Differential Revision: https://reviews.llvm.org/D31540 llvm-svn: 300443
* Add an explicit derived class of FunctionDecl to model deduction guides ratherRichard Smith2017-02-171-0/+1
| | | | | | | | than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-201-1/+4
| | | | | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
* Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."Daniel Jasper2016-12-191-4/+1
| | | | | | | This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-191-1/+4
| | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
* When a DecompositionDecl is marked invalid, also set the child BindingDecl's toRichard Trieu2016-11-111-1/+13
| | | | | | invalid. llvm-svn: 286630
* Add a note that points to the linkage specifier for the C++ linkage errorsAlex Lorenz2016-11-021-0/+12
| | | | | | | | | | | | This commit improves the "must have C++ linkage" error diagnostics that are emitted for C++ declarations like templates and literal operators by adding an additional note that points to the appropriate extern "C" linkage specifier. rdar://19021120 Differential Revision: https://reviews.llvm.org/D26189 llvm-svn: 285823
* Retire llvm::alignOf in favor of C++11 alignof.Benjamin Kramer2016-10-201-5/+3
| | | | | | No functionality change intended. llvm-svn: 284730
* [Modules TS] Diagnose 'export' declaration within 'export' declaration.Richard Smith2016-09-261-0/+16
| | | | llvm-svn: 282443
* Modules: revert r280728.Manman Ren2016-09-091-6/+4
| | | | | | | In post-commit review, Richard suggested a better way to fix this. rdar://27926200 llvm-svn: 281078
* C++ Modules TS: Add parsing and some semantic analysis support forRichard Smith2016-09-081-5/+7
| | | | | | | export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
* Modules: Fix an assertion in DeclContext::buildLookup.Manman Ren2016-09-061-4/+6
| | | | | | | | | | When calling getMostRecentDecl, we can pull in more definitions from a module. We call getPrimaryContext afterwards to make sure that we buildLookup on a primary context. rdar://27926200 llvm-svn: 280728
* Reapply r277058: "[ObjC] Consider availability of context when emitting ↵Erik Pilkington2016-07-291-12/+14
| | | | | | availability warnings" llvm-svn: 277175
* Revert "[ObjC] Consider availability of context when emitting availability ↵Erik Pilkington2016-07-281-14/+12
| | | | | | | | | | warnings" Reverting r277058, while I fugure out why it broke internal bots. This reverts commit e514ffa8b657416c6784bbe6da9f5de19365103d. llvm-svn: 277070
* [ObjC] Consider availability of context when emitting availability warningsErik Pilkington2016-07-281-12/+14
| | | | | | | | | | This means that a function marked with an availability attribute can safely refer to a declaration that is greater than the deployment target, but less then or equal to the context availability without -Wpartial-availability firing. Differential revision: https://reviews.llvm.org/D22697 llvm-svn: 277058
* P0217R3: Parsing support and framework for AST representation of C++1zRichard Smith2016-07-221-0/+2
| | | | | | | | | | | decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+0
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* Don't use static variables in LambdaCaptureJohn Brawn2016-06-151-3/+4
| | | | | | | | | | | | | | | | | | | | | | | When static variables are used in inline functions in header files anything that uses that function ends up with a reference to the variable. Because RecursiveASTVisitor uses the inline functions in LambdaCapture that use static variables any AST plugin that uses RecursiveASTVisitor, such as the PrintFunctionNames example, ends up with a reference to these variables. This is bad on Windows when building with MSVC with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON as variables used across a DLL boundary need to be explicitly dllimported in the DLL using them. This patch avoids that by adjusting LambdaCapture to be similar to before r263921, with a capture of either 'this' or a VLA represented by a null Decl pointer in DeclAndBits with an extra flag added to the bits to distinguish between the two. This requires the use of an extra bit, and while Decl does happen to be sufficiently aligned to allow this it's done in a way that means PointerIntPair doesn't realise it and gives an assertion failure. Therefore I also adjust Decl slightly to use LLVM_ALIGNAS to allow this. Differential Revision: http://reviews.llvm.org/D20732 llvm-svn: 272788
* Reland r267691 fixing PR27535.Vassil Vassilev2016-04-281-7/+11
| | | | llvm-svn: 267882
* Revert r267691, it caused PR27535.Nico Weber2016-04-271-11/+7
| | | | llvm-svn: 267744
* [modules] Fix Decl's Used invariant.Vassil Vassilev2016-04-271-7/+11
| | | | | | | | | | | | | | | | | | | | The Decl::isUsed has a value for every decl. In non-module builds it is very difficult (but possible) to break this invariant but when we walk up the redecl chain we find the neccessary information. When deserializing the decls from a module it is much more difficult to update correctly this invariant. The patch centralizes the information whether a decl is used in the canonical decl marking the entire entity as being used. Fixes https://llvm.org/bugs/show_bug.cgi?id=27401 Patch by Cristina Cristescu and me. Thanks to Richard Smith who helped to debug and understand the issue! Reviewed by Richard Smith. llvm-svn: 267691
* Warn if function or variable cannot be implicitly instantiatedSerge Pavlov2016-04-191-0/+11
| | | | | | | | | | | | With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
* [GCC] Attribute ifunc support in clangDmitry Polukhin2016-04-111-0/+12
| | | | | | | | | | | This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. LLVM patch http://reviews.llvm.org/D15525 Differential Revision: http://reviews.llvm.org/D15524 llvm-svn: 265917
* [modules] Don't try to add lookup results to non-lookup contexts.Vassil Vassilev2016-04-061-2/+5
| | | | | | | | Fixes https://llvm.org/bugs/show_bug.cgi?id=27186 Patch reviewed by Richard Smith. llvm-svn: 265597
* Sema: Treat 'strict' availability flag like unavailableDuncan P. N. Exon Smith2016-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | This is a follow-up to r261512, which made the 'strict' availability attribute flag behave like 'unavailable'. However, that fix was insufficient. The following case would (erroneously) error when the deployment target was older than 10.9: struct __attribute__((availability(macosx,strict,introduced=10.9))) A; __attribute__((availability(macosx,strict,introduced=10.9))) void f(A*); The use of A* in the argument list for f is valid here, since f and A have the same availability. The fix is to return AR_Unavailable from DeclBase::getAvailability instead of AR_NotYetIntroduced. This also reverts the special handling added in r261163, instead relying on the well-tested logic for AR_Unavailable. rdar://problem/23791325 llvm-svn: 262915
* [OPENMP 4.0] Initial support for 'omp declare reduction' construct.Alexey Bataev2016-03-031-0/+4
| | | | | | | | | | | | | | | | | Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
* Serialize `#pragma detect_mismatch`.Nico Weber2016-03-021-0/+1
| | | | | | | This is like r262493, but for pragma detect_mismatch instead of pragma comment. The two pragmas have similar behavior, so use the same approach for both. llvm-svn: 262506
* Serialize `#pragma comment`.Nico Weber2016-03-021-0/+1
| | | | | | | | | | | | | | `#pragma comment` was handled by Sema calling a function on ASTConsumer, and CodeGen then implementing this function and writing things to its output. Instead, introduce a PragmaCommentDecl AST node and hang one off the TranslationUnitDecl for every `#pragma comment` line, and then use the regular serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's eagerly deserialized.) http://reviews.llvm.org/D17799 llvm-svn: 262493
* SemaCXX: Support templates in availability attributesDuncan P. N. Exon Smith2016-02-261-0/+3
| | | | | | | | | | | | | | | | | | | If the availability context is `FunctionTemplateDecl`, we should look through it to the `FunctionDecl`. This prevents a diagnostic in the following case: class C __attribute__((unavailable)); template <class T> void foo(C&) __attribute__((unavailable)); This adds tests for availability in templates in many other cases, but that was the only case that failed before this patch. I added a feature `__has_feature(attribute_availability_in_templates)` so users can test for this. rdar://problem/24561029 llvm-svn: 262050
* [OPENMP] Rename OMPCapturedFieldDecl to OMPCapturedExprDecl, NFC.Alexey Bataev2016-02-111-1/+1
| | | | | | | | OMPCapturedExprDecl allows caopturing not only of fielddecls, but also other expressions. It also allows to simplify codegen for several clauses. llvm-svn: 260492
OpenPOWER on IntegriCloud