summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/Decl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ObjC++] Make parameter passing and function return compatible with ObjCAkira Hatanaka2018-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObjC and ObjC++ pass non-trivial structs in a way that is incompatible with each other. For example: typedef struct { id f0; __weak id f1; } S; // this code is compiled in c++. extern "C" { void foo(S s); } void caller() { // the caller passes the parameter indirectly and destructs it. foo(S()); } // this function is compiled in c. // 'a' is passed directly and is destructed in the callee. void foo(S a) { } This patch fixes the incompatibility by passing and returning structs with __strong or weak fields using the C ABI in C++ mode. __strong and __weak fields in a struct do not cause the struct to be destructed in the caller and __strong fields do not cause the struct to be passed indirectly. Also, this patch fixes the microsoft ABI bug mentioned here: https://reviews.llvm.org/D41039?id=128767#inline-364710 rdar://problem/38887866 Differential Revision: https://reviews.llvm.org/D44908 llvm-svn: 328731
* Sink PrettyDeclStackTrace down to the AST libraryJordan Rose2018-03-231-0/+19
| | | | | | | ...and add some very basic stack trace entries for module building. This would have helped track down rdar://problem/38434694 sooner. llvm-svn: 328276
* [ObjC] Allow declaring __weak pointer fields in C structs in ARC.Akira Hatanaka2018-03-191-1/+2
| | | | | | | | | | | | | | | | | | | This patch uses the infrastructure added in r326307 for enabling non-trivial fields to be declared in C structs to allow __weak fields in C structs in ARC. This recommits r327206, which was reverted because it caused module-enabled builders to fail. I discovered that the CXXRecordDecl::CanPassInRegisters flag wasn't being set correctly in some cases after I moved it to RecordDecl. Thanks to Eric Liu for helping me investigate the bug. rdar://problem/33599681 https://reviews.llvm.org/D44095 llvm-svn: 327870
* Revert "[ObjC] Allow declaring __weak pointer fields in C structs inAkira Hatanaka2018-03-121-2/+1
| | | | | | | | | | | ARC." This reverts commit r327206 as there were test failures caused by this patch. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180312/221427.html llvm-svn: 327294
* [ObjC] Allow declaring __weak pointer fields in C structs in ARC.Akira Hatanaka2018-03-101-1/+2
| | | | | | | | | | | | This patch uses the infrastructure added in r326307 for enabling non-trivial fields to be declared in C structs to allow __weak fields in C structs in ARC. rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D44095 llvm-svn: 327206
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-5/+5
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* [ObjC] Allow declaring __strong pointer fields in structs in Objective-CAkira Hatanaka2018-02-281-1/+3
| | | | | | | | | | | | | | | | | | | | | ARC mode. Declaring __strong pointer fields in structs was not allowed in Objective-C ARC until now because that would make the struct non-trivial to default-initialize, copy/move, and destroy, which is not something C was designed to do. This patch lifts that restriction. Special functions for non-trivial C structs are synthesized that are needed to default-initialize, copy/move, and destroy the structs and manage the ownership of the objects the __strong pointer fields point to. Non-trivial structs passed to functions are destructed in the callee function. rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D41228 llvm-svn: 326307
* [ODRHash] Fix hashing for friend functions.Richard Trieu2018-02-221-0/+6
| | | | | | | When hashing a templated function, use the hash of the function it was instantiated from. llvm-svn: 325742
* [AST] namespace ns { extern "C" { int X; }} prints as "ns::X", not as "X"Sam McCall2018-02-021-3/+4
| | | | llvm-svn: 324081
* [AST] Use bit packing to reduce sizeof(TypedefNameDecl) from 88 to 80.Benjamin Kramer2018-01-261-3/+1
| | | | | | | | We can stash the cached transparent tag bit in existing pointer padding. Everything coming out of ASTContext is always aligned to a multiple of 8, so we have 8 spare bits. llvm-svn: 323528
* [CUDA] CUDA has no device-side library builtins.Artem Belevich2018-01-231-0/+7
| | | | | | | | | | We should (almost) never consider a device-side declaration to match a library builtin functio. Otherwise clang may ignore the implementation provided by the CUDA headers and emit clang's idea of the builtin. Differential Revision: https://reviews.llvm.org/D42319 llvm-svn: 323239
* PR35697: look at the first declaration when determining whether a function orRichard Smith2018-01-031-3/+3
| | | | | | variable is extern "C" in linkage calculations. llvm-svn: 321686
* Fix comment typo in r321312.Paul Robinson2017-12-261-1/+1
| | | | | | Post-commit review by Kim Grasman! llvm-svn: 321457
* [ODRHash] Support ODR violation detection in functions.Richard Trieu2017-12-231-0/+20
| | | | | | | Extend the hashing to functions, which allows detection of function definition mismatches across modules. This is a re-commit of r320230. llvm-svn: 321395
* [AST] Incorrectly qualified unscoped enumeration as template actual parameter.Paul Robinson2017-12-211-1/+4
| | | | | | | | | | | | | | | An unscoped enumeration used as template argument, should not have any qualified information about its enclosing scope, as its visibility is global. In the case of scoped enumerations, they must include information about their enclosing scope. Patch by Carlos Alberto Enciso! Differential Revision: https://reviews.llvm.org/D39239 llvm-svn: 321312
* Revert r320230 to fix buildbots.Richard Trieu2017-12-091-20/+0
| | | | llvm-svn: 320239
* [ODRHash] Support ODR violation detection in functions.Richard Trieu2017-12-091-0/+20
| | | | | | | Extend the hashing to functions, which allows detection of function definition mismatches across modules. llvm-svn: 320230
* Generalize "static data member instantiated" notification to cover variable ↵Richard Smith2017-12-051-4/+16
| | | | | | | | | templates too. While here, split the "point of instantiation changed" notification out from it; these two really are orthogonal changes. llvm-svn: 319727
* PR35456: Track definedness of variable template specializations separately fromRichard Smith2017-12-021-3/+6
| | | | | | | | | | whether they have an initializer. We cannot distinguish between a declaration of a variable template specialization and a definition of one that lacks an initializer without this, and would previously mistake the latter for the former. llvm-svn: 319605
* Move comment back to being next to the code it's a comment for.Richard Smith2017-12-021-3/+3
| | | | llvm-svn: 319601
* Refactor functions PrintTemplateArgumentListSerge Pavlov2017-11-281-4/+2
| | | | | | | | | | | These functions were defined as static members of TemplateSpecializationType. Now they are moved to namespace level. Previously there were different implementations for lists containing TemplateArgument and TemplateArgumentLoc, now these implementations share the same code. This change is a result of refactoring patch D40508. NFC. llvm-svn: 319178
* [modules] Fix crash in complex class merging scenario.Richard Smith2017-11-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | When we merge together class definitions, we can end up with the canonical declaration of a field not being the one that was lexically within the canonical definition of the class. Additionally, when we merge class definitions via update records (eg, for a template specialization whose declaration is instantiated in one module and whose definition is instantiated in multiple others), we can end up with the list of lexical contents for the class not including a particular declaration of a field whose lexical parent is that class definition. In the worst case, we have a field whose canonical declaration's lexical parent has no fields, and in that case this attempt to number the fields by walking the fields in the declaration of the class that contained one of the canonical fields will fail. Instead, when numbering fields in a class, do the obvious thing: walk the fields in the definition. I'm still trying to reduce a testcase; the setup that leads to the above scenario seems to be quite fragile. llvm-svn: 318245
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-131-40/+62
| | | | | | minor fixes (NFC). llvm-svn: 318101
* [modules] Retain multiple using-directives in the same scope even if they ↵Richard Smith2017-10-301-8/+0
| | | | | | | | | | | | name the same namespace. They might have different visibility, and thus discarding all but one of them can result in rejecting valid code. Also fix name lookup to cope with multiple using-directives being found that denote the same namespace, where some are not visible -- don't cache an "already visited" state for a using-directive that we didn't visit because it was hidden. llvm-svn: 316965
* Enable support for the [[nodiscard]] attribute from WG14 N2050 when enabling ↵Aaron Ballman2017-10-171-1/+2
| | | | | | double square bracket attributes in C code. llvm-svn: 316026
* Support for destroying operator delete, per C++2a proposal P0722.Richard Smith2017-10-131-0/+14
| | | | | | | | | | This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-101-3/+15
| | | | | | | | | | | | | | | | | 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-13/+3
| | | | | | This reverts commit r315251. See the original commit thread for reason. llvm-svn: 315309
* Revert "[Modules TS] Avoid computing the linkage of the enclosing ↵Eric Liu2017-10-101-3/+1
| | | | | | | | DeclContext for a declaration in the global module." This reverts commit r315256. See the original commit thread for reason. llvm-svn: 315308
* [Modules TS] Avoid computing the linkage of the enclosing DeclContext for a ↵Richard Smith2017-10-101-1/+3
| | | | | | | | | | declaration in the global module. This works around a language issue where adding a typedef name for linkage purposes changes the linkage of an already-defined class after it becomes complete. llvm-svn: 315256
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-091-3/+13
| | | | | | | | | | 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
* R34811: Allow visibilities other than 'default' for VisibleNoLinkage entities.Richard Smith2017-10-031-2/+2
| | | | llvm-svn: 314754
* Allow specifying sanitizers in blacklistsVlad Tsyrklevich2017-09-251-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
* Correctly compute linkage for members of internal linkage classes.Richard Smith2017-09-231-5/+4
| | | | | | | We used to give such members no linkage instead of giving them the linkage of the class. llvm-svn: 314054
* DR1113: anonymous namespaces formally give their contents internal linkage.Richard Smith2017-09-221-6/+6
| | | | | | | | | | | | | | | | | | | | This doesn't affect our code generation in any material way -- we already give such declarations internal linkage from a codegen perspective -- but it has some subtle effects on code validity. We suppress the 'L' (internal linkage) marker for mangled names in anonymous namespaces, because it is redundant (the information is already carried by the namespace); this deviates from GCC's behavior if a variable or function in an anonymous namespace is redundantly declared 'static' (where GCC does include the 'L'), but GCC's behavior is incoherent because such a declaration can be validly declared with or without the 'static'. We still deviate from the standard in one regard here: extern "C" declarations in anonymous namespaces are still granted external linkage. Changing those does not appear to have been an intentional consequence of the standard change in DR1113. llvm-svn: 314037
* Closure types have no name (and can't have a typedef name for linkageRichard Smith2017-09-221-7/+8
| | | | | | purposes), so they never formally have linkage. llvm-svn: 313957
* Give external linkage and mangling to lambdas inside inline variables and ↵Richard Smith2017-09-221-50/+55
| | | | | | | | | | | variable templates. This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33 This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds enumeration value' ubsan error in that change. llvm-svn: 313955
* Clean up some mistreatment of enumerations.Richard Smith2017-09-221-39/+26
| | | | llvm-svn: 313953
* Revert "Give external linkage and mangling to lambdas inside inline ↵Vitaly Buka2017-09-211-16/+5
| | | | | | | | | | variables and variable templates." To fix: runtime error: load of value 15, which is not a valid value for type 'clang::LVComputationKind' This reverts commit r313827. llvm-svn: 313856
* Give external linkage and mangling to lambdas inside inline variables and ↵Richard Smith2017-09-201-5/+16
| | | | | | | | variable templates. This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33 llvm-svn: 313827
* Implement C++ [basic.link]p8.Richard Smith2017-09-201-5/+7
| | | | | | | | | | | | | | If a function or variable has a type with no linkage (and is not extern "C"), any use of it requires a definition within the same translation unit; the idea is that it is not possible to define the entity elsewhere, so any such use is necessarily an error. There is an exception, though: some types formally have no linkage but nonetheless can be referenced from other translation units (for example, this happens to anonymous structures defined within inline functions). For entities with those types, we suppress the diagnostic except under -pedantic. llvm-svn: 313729
* Implement Itanium name mangling support for C++ Modules TS.Richard Smith2017-09-041-1/+25
| | | | | | | | | | | | This follows the scheme agreed with Nathan Sidwell, which can be found here: https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile This will be proposed to the itanium-cxx-abi list once we have some experience with how well it works; the ABI for this TS should be considered unstable until it is part of the Itanium C++ ABI. llvm-svn: 312467
* [c++2a] P0683R1: Permit default member initializers for bit-fields.Richard Smith2017-08-281-16/+8
| | | | | | | This would be trivial, except that our in-memory and serialized representations for FieldDecls assumed that this can't happen. llvm-svn: 311867
* [AST] Cache intermediate visibility/linkage resultsGeorge Burgess IV2017-08-091-4/+8
| | | | | | | | | | | | This is a follow-up to r310436 with actual functional changes. Please see that commit message for a description of why a cache is appearing here. Suggestions for less-bad ways of testing this are appreciated. :) This fixes PR29160. llvm-svn: 310437
* [AST] Move visibility computations into a class; NFCGeorge Burgess IV2017-08-091-114/+73
| | | | | | | | | | | | | | | | | | | | | This is patch 1 in a 2 patch series that aims to fix PR29160. Its goal is to cache decl visibility/linkage for the duration of each visibility+linkage query. The simplest way I can see to do this is to put the visibility calculation code that needs to (transitively) access this cache into a class, which is what this patch does. Actual caching will come in patch 2. (Another way would be to keep the cache in ASTContext + manually invalidate it or something, but that felt way too subtle to me.) Caching visibility results across multiple queries seems a bit tricky, since the user can add visibility attributes ~whenever they want, and these attributes can apparently have far-reaching effects (e.g. class visibility extends to its members, ...). Because a cache that's dropped at the end of each top-level query seems to work nearly as well and doesn't require any eviction logic, I opted for that design. llvm-svn: 310436
* [Availability] Don't make an availability attribute imply default visibility ↵Erik Pilkington2017-08-081-8/+0
| | | | | | | | | | on macOS Fixes PR33796, rdar://33655115 Differential revision: https://reviews.llvm.org/D36191 llvm-svn: 310382
* Mark static variables static; NFC.George Burgess IV2017-08-071-2/+2
| | | | llvm-svn: 310299
* [modules ts] Basic for module linkage.Richard Smith2017-07-071-14/+64
| | | | | | | | | | In addition to the formal linkage rules, the Modules TS includes cases where internal-linkage symbols within a module interface unit can be referenced from outside the module via exported inline functions / templates. We give such declarations "module-internal linkage", which is formally internal linkage, but results in an externally-visible symbol. llvm-svn: 307434
* [modules] Teach clang how to merge typedef over anonymous structs in C mode.Vassil Vassilev2017-07-011-2/+1
| | | | | | | | | | In C mode clang fails to merge the textually included definition with the one imported from a module. The C lookup rules fail to find the imported definition because its linkage is internal in non C++ mode. This patch reinstates some of the ODR merging rules for typedefs of anonymous tags for languages other than C++. Patch by Raphael Isemann and me (D34510). llvm-svn: 306964
* Change enumerator default linkage type for CBruno Cardoso Lopes2017-07-011-1/+3
| | | | | | | | | | | | | | | Redeclaration lookup should never find hidden enumerators in C, because they do not have linkage (C11 6.2.2/6) The linkage of an enumerator should be VisibleNoLinkage, and isHiddenDeclarationVisible should be checking hasExternalFormalLinkage. This is was reviewed as part of D31778, but splitted into a different commit for clarity. rdar://problem/31909368 llvm-svn: 306917
OpenPOWER on IntegriCloud