summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/Decl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[Sema] Diagnose default-initialization, destruction, and copying of"Akira Hatanaka2019-07-261-3/+0
| | | | | | | | | | | | | | | This reverts commit r365985. Prior to r365985, clang used to mark C union fields that have non-trivial ObjC ownership qualifiers as unavailable if the union was declared in a system header. r365985 stopped doing so, which caused the swift compiler to crash when it tried to import a non-trivial union. I have a patch that fixes the crash (https://reviews.llvm.org/D65256), but I'm temporarily reverting the original patch until we can decide on whether it's taking the right approach. llvm-svn: 367076
* Initialize the non-trivial C union bits I added to RecordDeclBitfieldsAkira Hatanaka2019-07-131-0/+3
| | | | | | | | | | in r365985 These bits weren't being initialized in the RecordDecl's constructor, which probably caused test/Modules/stress1.cpp to fail on a couple of bots. llvm-svn: 365989
* P0840R2: support for [[no_unique_address]] attributeRichard Smith2019-06-201-0/+33
| | | | | | | | | | | | | | | | | Summary: Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI. This depends on D63371. Reviewers: rjmccall, aaron.ballman Subscribers: dschuff, aheejin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63451 llvm-svn: 363976
* Fix crash when checking a dependently-typed reference that isRichard Smith2019-06-171-1/+1
| | | | | | initialized from a non-value-dependent initializer. llvm-svn: 363622
* [C++20] add Basic consteval specifierGauthier Harnisch2019-06-141-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration. Changes: - add the consteval keyword. - add parsing of consteval specifier for normal declarations and lambdas expressions. - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval. - adapt diagnostic about constexpr to print constexpr or consteval depending on the case. - add tests for basic semantic. Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: eraman, efriedma, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61790 llvm-svn: 363362
* For DR712: store on a DeclRefExpr whether it constitutes an odr-use.Richard Smith2019-06-111-1/+21
| | | | | | | Begin restructuring to support the forms of non-odr-use reference permitted by DR712. llvm-svn: 363086
* Refactor: split Uninitialized state on APValue into an "Absent" stateRichard Smith2019-05-211-1/+1
| | | | | | | representing no such object, and an "Indeterminate" state representing an uninitialized object. The latter is not yet used, but soon will be. llvm-svn: 361328
* [c++20] P0780R2: Support pack-expansion of init-captures.Richard Smith2019-05-211-4/+4
| | | | | | | | | | | This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
* Revert r360637 "PR41817: Fix regression in r359260 that caused the MS ↵Hans Wennborg2019-05-141-35/+6
| | | | | | | | | | | | compatibility" > extension allowing a "static" declaration to follow an "extern" > declaration to stop working. It introduced asserts for some "static-following-extern" cases, breaking the Chromium build. See the cfe-commits thread for reproducer. llvm-svn: 360657
* PR41817: Fix regression in r359260 that caused the MS compatibilityRichard Smith2019-05-141-6/+35
| | | | | | | extension allowing a "static" declaration to follow an "extern" declaration to stop working. llvm-svn: 360637
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-091-1/+0
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [OpenCL] Prevent mangling kernel functions.Anastasia Stulova2019-05-071-0/+2
| | | | | | | | | | | | Kernel function names have to be preserved as in the original source to be able to access them from the host API side. This commit also adds restriction to kernels that prevents them from being used in overloading, templates, etc. Differential Revision: https://reviews.llvm.org/D60454 llvm-svn: 360152
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-041-1/+0
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* CWG issue 727: Fix numerous bugs in support for class-scope explicitRichard Smith2019-05-031-39/+63
| | | | | | specializations for variable templates. llvm-svn: 359947
* Replace ad-hoc tracking of pattern for an instantiated class-scopeRichard Smith2019-05-021-45/+74
| | | | | | | | | | explicit function specialization with the MemberSpecializationInfo used everywhere else. Not NFC: the ad-hoc pattern tracking was not being serialized / deserialized properly. That's fixed here. llvm-svn: 359747
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-261-30/+51
| | | | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. This reinstates part of r359048, reverted in r359076. llvm-svn: 359260
* Revert r359048: C++ DR2387: a variable template declared wthiIlya Biryukov2019-04-241-51/+30
| | | | | | | | | | | | | The change breaks libc++ with the follwing error: In file included from valarray:4: .../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t)) ^ .../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray()) llvm-svn: 359076
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-231-30/+51
| | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. llvm-svn: 359048
* Fix overly-long line after r358731.Richard Smith2019-04-191-2/+2
| | | | llvm-svn: 358733
* Fix typo in function name [NFC]Ali Tamur2019-04-191-3/+3
| | | | llvm-svn: 358731
* [c++2a] Add semantic support for private module fragments.Richard Smith2019-04-181-10/+18
| | | | llvm-svn: 358713
* Special case ObjCPropertyDecl for printingDavid Goldman2019-04-041-1/+7
| | | | | | | | ObjCPropertyDecl should use the category interface as a context similar to what is done for methods. Previously category methods would be printed as `::property`; now they are printed as `Class::property`. llvm-svn: 357720
* [Sema] Add some compile time _FORTIFY_SOURCE diagnosticsErik Pilkington2019-03-181-11/+15
| | | | | | | | | | | | | | | | | | | | | | | These diagnose overflowing calls to subset of fortifiable functions. Some functions, like sprintf or strcpy aren't supported right not, but we should probably support these in the future. We previously supported this kind of functionality with -Wbuiltin-memcpy-chk-size, but that diagnostic doesn't work with _FORTIFY implementations that use wrapper functions. Also unlike that diagnostic, we emit these warnings regardless of whether _FORTIFY_SOURCE is actually enabled, which is nice for programs that don't enable the runtime checks. Why not just use diagnose_if, like Bionic does? We can get better diagnostics in the compiler (i.e. mention the sizes), and we have the potential to diagnose sprintf and strcpy which is impossible with diagnose_if (at least, in languages that don't support C++14 constexpr). This approach also saves standard libraries from having to add diagnose_if. rdar://48006655 Differential revision: https://reviews.llvm.org/D58797 llvm-svn: 356397
* Avoid needlessly copying a block to the heap when a block literalAkira Hatanaka2019-02-271-0/+1
| | | | | | | | | | | | initializes a local auto variable or is assigned to a local auto variable that is declared in the scope that introduced the block literal. rdar://problem/13289333 https://reviews.llvm.org/D58514 llvm-svn: 355012
* [Builtins] Treat `bcmp` as a builtin.Clement Courbet2019-02-141-0/+6
| | | | | | | | | | | | | | | | | Summary: This makes it consistent with `memcmp` and `__builtin_bcmp`. Also see the discussion in https://reviews.llvm.org/D56593. Reviewers: jyknight Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58120 llvm-svn: 354023
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Diagnose an unused result from a call through a function pointer whose ↵Aaron Ballman2019-01-031-14/+0
| | | | | | | | | | return type is marked [[nodiscard]]. When a function returns a type and that type was declared [[nodiscard]], we diagnose any unused results from that call as though the function were marked nodiscard. The same behavior should apply to calls through a function pointer. This addresses PR31526. llvm-svn: 350317
* Fix up diagnostics.Richard Trieu2018-12-141-1/+1
| | | | | | | | | | | Move some diagnostics around between Diagnostic*Kinds.td files. Diagnostics used in multiple places were moved to DiagnosticCommonKinds.td. Diagnostics listed in the wrong place (ie, Sema diagnostics listed in DiagnosticsParseKinds.td) were moved to the correct places. One diagnostic split into two so that the diagnostic string is in the .td file instead of in code. Cleaned up the diagnostic includes after all the changes. llvm-svn: 349125
* [AST] Fix an uninitialized bug in the bits of FunctionDeclBruno Ricci2018-12-031-21/+23
| | | | | | | FunctionDeclBits.IsCopyDeductionCandidate was not initialized. This caused a warning with valgrind. llvm-svn: 348131
* [NFC] Move MultIversioning::Type into Decl so that it can be used inErich Keane2018-11-281-0/+11
| | | | | | | CodeGen Change-Id: I32b14edca3501277e0e65672eafe3eea38c6f9ae llvm-svn: 347791
* Pass the function type instead of the return type to FunctionDecl::CreateJonas Devlieghere2018-11-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix places where the return type of a FunctionDecl was being used in place of the function type FunctionDecl::Create() takes as its T parameter the type of function that should be created, not the return type. Passing in the return type looks to have been copypasta'd around a bit, but the number of correct usages outweighs the incorrect ones so I've opted for keeping what T is the same and fixing up the call sites instead. This fixes a crash in Clang when attempting to compile the following snippet of code with -fblocks -fsanitize=function -x objective-c++ (my original repro case): void g(void(^)()); void f() { __block int a = 0; g(^(){ a++; }); } as well as the following which only requires -fsanitize=function -x c++: void f(char * buf) { __builtin_os_log_format(buf, ""); } Patch by: Ben (bobsayshilol) Differential revision: https://reviews.llvm.org/D53263 llvm-svn: 346601
* Create ConstantExpr classBill Wendling2018-10-311-1/+1
| | | | | | | | | | | | | | | | A ConstantExpr class represents a full expression that's in a context where a constant expression is required. This class reflects the path the evaluator took to reach the expression rather than the syntactic context in which the expression occurs. In the future, the class will be expanded to cache the result of the evaluated expression so that it's not needlessly re-evaluated Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D53475 llvm-svn: 345692
* Implement Function Multiversioning for Non-ELF Systems.Erich Keane2018-10-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the resolver function directly to forward the call to the proper function. This is not nearly as efficient as IFuncs of course, but is still quite useful for large functions specifically developed for certain processors. This is unfortunately still limited to x86, since it depends on __builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins. The naming for the resolver/forwarding function for cpu-dispatch was taken from ICC's implementation, which uses the unmodified name for this (no mangling additions). This is possible, since cpu-dispatch uses '.A' for the 'default' version. In 'target' multiversioning, this function keeps the '.resolver' extension in order to keep the default function keeping the default mangling. Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284 Differential Revision: https://reviews.llvm.org/D53586 llvm-svn: 345298
* [AST] Use -fvisibility value when ignoring -fv-i-h* inline static localsReid Kleckner2018-10-101-7/+17
| | | | | | | | | | | | | | | | | | | | | | Summary: In r340386 we added code to give static locals in inline functions default visibility. Instead, we should use the "default" visibility passed on the command line, which could be hidden or protected, as GCC does. Some code bases use both -fvisibility=hidden and -fvisibility-inlines-hidden to hide inline functions of classes that are explicitly marked with default visibility. Fixes PR39236 Reviewers: hans, thakis Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D53052 llvm-svn: 344190
* [HIP] Support early finalization of device code for -fno-gpu-rdcYaxun Liu2018-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This patch renames -f{no-}cuda-rdc to -f{no-}gpu-rdc and keeps the original options as aliases. When -fgpu-rdc is off, clang will assume the device code in each translation unit does not call external functions except those in the device library, therefore it is possible to compile the device code in each translation unit to self-contained kernels and embed them in the host object, so that the host object behaves like usual host object which can be linked by lld. The benefits of this feature is: 1. allow users to create static libraries which can be linked by host linker; 2. amortized device code linking time. This patch modifies HIP action builder to insert actions for linking device code and generating HIP fatbin, and pass HIP fatbin to host backend action. It extracts code for constructing command for generating HIP fatbin as a function so that it can be reused by early finalization. It also modifies codegen of HIP host constructor functions to embed the device fatbin when it is available. Differential Revision: https://reviews.llvm.org/D52377 llvm-svn: 343611
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-10-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. This reapplies r343518 after fixing a use-after-free bug in function Sema::ActOnBlockStmtExpr where the BlockScopeInfo was dereferenced after it was popped and deleted. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 343542
* Revert r343518.Akira Hatanaka2018-10-011-8/+0
| | | | | | | | | Bots are still failing. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/24420 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12958 llvm-svn: 343531
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-10-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. This reapplies r341754, which was reverted in r341757 because it broke a couple of bots. r341754 was calling markEscapingByrefs after the call to PopFunctionScopeInfo, which caused the popped function scope to be cleared out when the following code was compiled, for example: $ cat test.m struct A { id data[10]; }; void foo() { __block A v; ^{ (void)v; }; } This commit calls markEscapingByrefs before calling PopFunctionScopeInfo to prevent that from happening. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 343518
* Revert r341754.Akira Hatanaka2018-09-091-8/+0
| | | | | | | | | The commit broke a couple of bots: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12347 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/7310 llvm-svn: 341757
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-09-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 341754
* [AST] correct the behavior of -fvisibility-inlines-hidden option (don't make ↵Hiroshi Inoue2018-08-221-0/+10
| | | | | | | | | | | | | static local variables hidden) The command line option -fvisibility-inlines-hidden makes inlined method hidden, but it is expected not to affect the visibility of static local variables in the function. However, Clang makes the static local variables in the function also hidden as reported in PR37595. This problem causes LLVM bootstarp failure on Fedora 28 if configured with -DBUILD_SHARED_LIBS=ON. This patch makes the behavior of -fvisibility-inlines-hidden option to be consistent with that of gcc; the option does not change the visibility of the static local variables if the containing function does not associated with explicit visibility attribute and becomes hidden due to this option. Differential Revision: https://reviews.llvm.org/D50968 llvm-svn: 340386
* Add a new flag and attributes to control static destructor registrationErik Pilkington2018-08-211-0/+6
| | | | | | | | | | | | | | | | | | | | This commit adds the flag -fno-c++-static-destructors and the attributes [[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a specific static or thread duration variable shouldn't have it's destructor registered, and is the default in -fno-c++-static-destructors mode. always_destroy is the opposite, and is the default in -fc++-static-destructors mode. A variable whose destructor is disabled (either because of -fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of the destructor, so we don't do any access checking or mark it referenced. We also don't emit -Wexit-time-destructors for these variables. rdar://21734598 Differential revision: https://reviews.llvm.org/D50994 llvm-svn: 340306
* Port getLocEnd -> getEndLocStephen Kelly2018-08-091-5/+5
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-5/+5
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* [AST][3/4] Move the bit-fields from BlockDecl, LinkageSpecDecl and ↵Erich Keane2018-08-011-1/+10
| | | | | | | | | | | | | | | | | OMPDeclareReductionDecl into DeclContext This patch follows https://reviews.llvm.org/D49729 and https://reviews.llvm.org/D49732, and is followed by https://reviews.llvm.org/D49734. Move the bits from BlockDecl, LinkageSpecDecl and OMPDeclareReductionDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49733 Patch By: bricci llvm-svn: 338639
* [AST][2/4] Move the bit-fields from FunctionDecl and CXXConstructorDecl into ↵Erich Keane2018-08-011-8/+40
| | | | | | | | | | | | | | | | | DeclContext This patch follows https://reviews.llvm.org/D49729 and is followed by https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734. Move the bits from FunctionDecl and CXXConstructorDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49732 Patch By: bricci llvm-svn: 338636
* [AST][1/4] Move the bit-fields from TagDecl, EnumDecl and RecordDecl into ↵Erich Keane2018-08-011-20/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclContext DeclContext has a little less than 8 bytes free due to the alignment requirements on 64 bits archs. This set of patches moves the bit-fields from classes deriving from DeclContext into DeclContext. On 32 bits archs this increases the size of DeclContext by 4 bytes but this is balanced by an equal or larger reduction in the size of the classes deriving from it. On 64 bits archs the size of DeclContext stays the same but most of the classes deriving from it shrink by 8/16 bytes. (-print-stats diff here https://reviews.llvm.org/D49728) When doing an -fsyntax-only on all of Boost this result in a 3.6% reduction in the size of all Decls and a 1% reduction in the run time due to the lower cache miss rate. For now CXXRecordDecl is not touched but there is an easy 6 (if I count correctly) bytes gain available there by moving some bits from DefinitionData into the free space of DeclContext. This will be the subject of another patch. This patch sequence also enable the possibility of refactoring FunctionDecl: To save space some bits from classes deriving from FunctionDecl were moved to FunctionDecl. This resulted in a lot of stuff in FunctionDecl which do not belong logically to it. After this set of patches however it is just a simple matter of adding a SomethingDeclBitfields in DeclContext and moving the bits to it from FunctionDecl. This first patch introduces the anonymous union in DeclContext and all the *DeclBitfields classes holding the bit-fields, and moves the bits from TagDecl, EnumDecl and RecordDecl into DeclContext. This patch is followed by https://reviews.llvm.org/D49732, https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734. Differential Revision: https://reviews.llvm.org/D49729 Patch By: bricci llvm-svn: 338630
* Remove trailing spaceFangrui Song2018-07-301-60/+60
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [AST] Add a convenient getter from QualType to RecordDeclGeorge Karpenkov2018-07-281-6/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D49951 llvm-svn: 338187
OpenPOWER on IntegriCloud