summaryrefslogtreecommitdiffstats
path: root/clang/include
Commit message (Collapse)AuthorAgeFilesLines
...
* [ASTImporter] Load external Decls when getting field index.Balazs Keri2018-08-081-0/+7
| | | | | | | | | | | | | | | | | Summary: At equality check of fields without name the index of fields is compared. At determining the index of a field all fields of the parent context should be loaded from external source to find the field at all. Reviewers: a.sidorin, a_sidorin, r.stahl Reviewed By: a.sidorin Subscribers: martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49796 llvm-svn: 339226
* [OPENMP] Mark variables captured in declare target region as implicitlyAlexey Bataev2018-08-071-3/+4
| | | | | | | | | declare target. According to OpenMP 5.0, variables captured in lambdas in declare target regions must be considered as implicitly declare target. llvm-svn: 339152
* [AST][NFC] Use unsigned in the bit-fields of IdentifierInfoBruno Ricci2018-08-071-30/+54
| | | | | | | Avoid mixing bool and unsigned in the bit-fields of IdentifierInfo since MSVC packs this poorly. Also clang-format the changes. llvm-svn: 339134
* [AST][NFC] Use unsigned in the bit-fields of PrintingPolicyBruno Ricci2018-08-071-12/+12
| | | | | | | Avoid the mix between bools and unsigned since MSVC pack this poorly. llvm-svn: 339132
* AMDGPU: Add builtin for s_dcache_wbMatt Arsenault2018-08-071-0/+1
| | | | llvm-svn: 339110
* AMDGPU: Add builtin for s_dcache_inv_volMatt Arsenault2018-08-071-0/+5
| | | | llvm-svn: 339109
* [analyzer] pr37204: Take signedness into account in getTruthValue().Artem Dergachev2018-08-071-1/+2
| | | | | | | | | | | It now actually produces a signed APSInt when the QualType passed into it is signed, which is what any caller would expect. Fixes a couple of crashes. Differential Revision: https://reviews.llvm.org/D50363 llvm-svn: 339088
* [analyzer] NFC: Document that we support implicit argument constructors.Artem Dergachev2018-08-071-3/+10
| | | | | | | | | | | | | | The change in the AST in r338135 caused us to accidentally support inlining constructors of operator implicit arguments. Previously they were hard to support because they were treated as arguments in expressions but not in declarations, but now they can be transparently treated as simple temporaries. Add tests and comments to explain how it now works. Differential Revision: https://reviews.llvm.org/D49627 llvm-svn: 339087
* Performing a test commmit as requested by Chris Lattner.Balaji V. Iyer2018-08-071-1/+1
| | | | | | | | -This line, and those below, will be ignored-- M TemplateBase.h llvm-svn: 339085
* [analyzer] Add ASTContext to CheckerManagerGeorge Karpenkov2018-08-063-8/+10
| | | | | | | | | Some checkers require ASTContext. Having it in the constructor saves a lot of boilerplate of having to pass it around. Differential Revision: https://reviews.llvm.org/D50111 llvm-svn: 339079
* [NFC] Remove TODO comment that no longer applies (ParsedAttr)Erich Keane2018-08-061-1/+1
| | | | llvm-svn: 339039
* [AST] Remove unnecessary indirections in DeclarationNameTableBruno Ricci2018-08-061-14/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclarationNameTable currently hold 3 "void *" to FoldingSet<CXXSpecialName>, FoldingSet<CXXLiteralOperatorIdName> and FoldingSet<CXXDeductionGuideNameExtra>. CXXSpecialName, CXXLiteralOperatorIdName and CXXDeductionGuideNameExtra are private classes holding extra information about a "special" declaration name and are in AST/DeclarationName.cpp. The original intent seems to have been to keep these classes private and only expose DeclarationNameExtra and DeclarationName (the code dates from 2008 and has not been significantly changed since). However this make the code less straightforward than necessary because of the need to have "void *" in DeclarationNameTable (with 1 of 3 comments wrong) and to manually allocate/deallocate the FoldingSets. Moreover removing the extra indirections reduce the run-time of an fsyntax-only on all of Boost by 2.3% which is not totally unexpected given how frequently this data structure is used (especially for C++). A concern raised by erichkeane during the review was that including Type.h would increase the compile time unreasonably. However test builds (both clean and incremental) showed that this patch did not result in any compile time increase. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D50261 llvm-svn: 339030
* [Fixed Point Arithmetic] Fixed Point ConstantLeonard Chan2018-08-063-0/+151
| | | | | | | | | | This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values. Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum. Differential Revision: https://reviews.llvm.org/D48661 llvm-svn: 339028
* [Fixed Point Arithmetic] Fix for FixedPointValueToStringLeonard Chan2018-08-061-3/+2
| | | | | | | | | | | | - Print negative numbers correctly - Handle APInts of different sizes - Add formal unit tests for FixedPointValueToString - Add tests for checking correct printing when padding is set - Restrict to printing in radix 10 since that's all we need for now Differential Revision: https://reviews.llvm.org/D49945 llvm-svn: 339026
* [AST] Move the enum in ObjCMethodDeclBitfieldsBruno Ricci2018-08-061-2/+3
| | | | | | | | | | Move the enum { ObjCMethodFamilyBitWidth = 4 } to the top of the class. For some dark reason having the enum between the bitfields breaks the packing with gcc version 7.3-win32 20180312. Reported by: Abramo Bagnara (by email) llvm-svn: 339017
* clang-cl: Parse the new /JMC flagHans Wennborg2018-08-061-0/+1
| | | | llvm-svn: 339008
* [AST][NFC] Remove unneeded forward declarations in Type.hBruno Ricci2018-08-051-16/+1
| | | | | | | | These forward declarations for various classes in the Type hierarchy are not needed since they are all forward declared systematically a few lines below. llvm-svn: 338966
* [constexpr] Support for constant evaluation of __builtin_memcpy andRichard Smith2018-08-042-0/+18
| | | | | | | | | | | | | | | | | | __builtin_memmove (in non-type-punning cases). This is intended to permit libc++ to make std::copy etc constexpr without sacrificing the optimization that uses memcpy on trivially-copyable types. __builtin_strcpy and __builtin_wcscpy are not handled by this change. They'd be straightforward to add, but we haven't encountered a need for them just yet. This reinstates r338455, reverted in r338602, with a fix to avoid trying to constant-evaluate a memcpy call if either pointer operand has an invalid designator. llvm-svn: 338941
* [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.Volodymyr Sapsai2018-08-032-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libc++ needs to know when aligned allocation is supported by clang, but is otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with alignment arguments. This patch implements the following changes: * The `__cpp_aligned_new` feature test macro to no longer be defined when aligned allocation is otherwise enabled but unavailable. * The Darwin driver no longer passes `-faligned-alloc-unavailable` when the user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`. * Instead of a warning Clang now generates a hard error when an aligned allocation or deallocation function is referenced but unavailable. Patch by Eric Fiselier. Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith Reviewed By: rsmith Subscribers: Quuxplusone, cfe-commits Differential Revision: https://reviews.llvm.org/D45015 llvm-svn: 338934
* [NFCI] My attempt to fix a warning in r338886 broke the build! Fix it.Erich Keane2018-08-031-1/+1
| | | | | | | | Clang format got the best of me... it introduced spaces around something in a table-genned file, so it was interpreted as an array and not a code block. llvm-svn: 338889
* [AST][NFC] Add missing doc for ObjCMethodDecl and ObjCContainerDeclBruno Ricci2018-08-031-0/+6
| | | | | | | | | | | Add a comment in ObjCMethodDecl and ObjCContainerDecl stating that we store some bits in ObjCMethodDeclBits and ObjCContainerDeclBits. This was missed by the recent move in r338641 : [AST][4/4] Move the bit-fields from ObjCMethodDecl and ObCContainerDecl into DeclContext llvm-svn: 338888
* [AST][NFC] Small doc update for DeclContextBruno Ricci2018-08-031-8/+15
| | | | | | | | | | | | | | | | Factored out from https://reviews.llvm.org/D49729 following @erichkeane comments. * Add missing classes in the list of classes deriving directly from DeclContext. * Move the friend declarations together and add a comment for why they are required. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D49790 llvm-svn: 338887
* [NFC] Fix unused expression warning introduced in r338884Erich Keane2018-08-031-2/+3
| | | | llvm-svn: 338886
* [NFC] Silence unused variable warning in Attr.td/AttrParsedAttrImpl.incErich Keane2018-08-031-1/+1
| | | | llvm-svn: 338884
* [libclang 8/8] Add support for the flag_enum attributeMichael Wu2018-08-031-2/+3
| | | | | | | | | | | | | | | | | Summary: This adds support to libclang for reading the flag_enum attribute. This also bumps CINDEX_VERSION_MINOR for this patch series. Reviewers: yvvan, jbcoe Reviewed By: yvvan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49635 llvm-svn: 338820
* [libclang 7/8] Add support for getting property setter and getter namesMichael Wu2018-08-031-0/+12
| | | | | | | | | | | | | | Summary: This allows libclang to access the actual names of property setters and getters without needing to go through the indexer API. Usually default names are used, but the property can specify a different name. Reviewers: yvvan, jbcoe Reviewed By: yvvan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49634 llvm-svn: 338816
* [libclang 6/8] Add support for reading implicit attributesMichael Wu2018-08-031-1/+6
| | | | | | | | | | | | | | | | | Summary: Having access to implicit attributes is sometimes useful so users of libclang don't have to duplicate some of the logic in sema. This depends on D49081 since it also adds a CXTranslationUnit flag. Reviewers: yvvan, jbcoe Reviewed By: yvvan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49631 llvm-svn: 338815
* [libclang 5/8] Add support for ObjC attributes without argsMichael Wu2018-08-031-1/+18
| | | | | | | | | | | | | | | | | Summary: This adds support to libclang for identifying ObjC related attributes that don't take arguments. All attributes but NSObject and NSConsumed are tested. Reviewers: yvvan, jbcoe Reviewed By: yvvan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49127 llvm-svn: 338813
* [libclang 4/8] Add the clang_Type_getNullability() APIMichael Wu2018-08-031-0/+27
| | | | | | | | | | | | | | | | | Summary: This patch adds a clang-c API for querying the nullability of an AttributedType. The test here also tests D49081 Reviewers: yvvan, jbcoe Reviewed By: yvvan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49082 llvm-svn: 338809
* [libclang 3/8] Add support for AttributedTypeMichael Wu2018-08-031-2/+15
| | | | | | | | | | | | | | | | | | | Summary: This patch adds support to the libclang API for identifying AttributedTypes in CXTypes and reading the modified type that the type points to. Currently AttributedTypes are skipped. This patch continues to skip AttributedTypes by default, but adds a parsing option to CXTranslationUnit to include AttributedTypes. This patch depends on D49066 since it also adds a CXType. Testing will be added in another patch which depends on this one. Reviewers: yvvan, jbcoe Reviewed By: yvvan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49081 llvm-svn: 338808
* [libclang 2/8] Add support for ObjCTypeParamMichael Wu2018-08-031-1/+2
| | | | | | | | | | | | | | | | | Summary: This patch adds support to the libclang API for identifying ObjCTypeParams in CXTypes. This patch depends on D49063 since both patches add new values to CXTypeKind. Reviewers: yvvan, jbcoe Reviewed By: yvvan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49066 llvm-svn: 338807
* [libclang 1/8] Add support for ObjCObjectTypeMichael Wu2018-08-031-1/+40
| | | | | | | | | | | | | | Summary: This patch adds support to the clang-c API for identifying ObjCObjects in CXTypes, enumerating type args and protocols on ObjCObjectTypes, and retrieving the base type of ObjCObjectTypes. Currently only ObjCInterfaceTypes are exposed, which do not have type args or protocols. Reviewers: yvvan, jbcoe Reviewed By: yvvan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49063 llvm-svn: 338804
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-031-10/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
* [modules] Defer merging deduced return types.Richard Smith2018-08-031-0/+11
| | | | | | | | | | | We can't read a deduced return type until we are sure that the types referred to by it are not in the middle of being loaded. So defer all reading of such deduced return types until the end of the recursive deserialization step. Also, when we load a function type that has a deduced return type, update all other redeclarations of the function to have that deduced return type. llvm-svn: 338798
* [WebAssembly] Support for atomic.wait / atomic.wake builtinsHeejin Ahn2018-08-021-0/+5
| | | | | | | | | | | | | | Summary: Add support for atomic.wait / atomic.wake builtins based on the Wasm thread proposal. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits Differential Revision: https://reviews.llvm.org/D49396 llvm-svn: 338771
* AMDGPU: Fix missing declaration of queue ptr builtinMatt Arsenault2018-08-021-0/+1
| | | | llvm-svn: 338754
* [analyzer] Forward arguments in registerChecker to avoid accidental copiesGeorge Karpenkov2018-08-021-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D50108 llvm-svn: 338753
* Try to make builtin address space declarations not uselessMatt Arsenault2018-08-023-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way address space declarations for builtins currently work is nearly useless. The code assumes the address spaces used for builtins is a confusingly named "target address space" from user code using __attribute__((address_space(N))) that matches the builtin declaration. There's no way to use this to declare a builtin that returns a language specific address space. The terminology used is highly cofusing since it has nothing to do with the the address space selected by the target to use for a language address space. This feature is essentially unused as-is. AMDGPU and NVPTX are the only in-tree targets attempting to use this. The AMDGPU builtins certainly do not behave as intended (i.e. all of the builtins returning pointers can never compile because the numbered address space never matches the expected named address space). The NVPTX builtins are missing tests for some, and the others seem to rely on an implicit addrspacecast. Change the used address space for builtins based on a target hook to allow using a language address space for a builtin. This allows the same builtin declaration to be used for multiple languages with similarly purposed address spaces (e.g. the same AMDGPU builtin can be used in OpenCL and CUDA even though the constant address spaces are arbitarily different). This breaks the possibility of using arbitrary numbered address spaces alongside the named address spaces for builtins. If this is an issue we probably need to introduce another builtin declaration character to distinguish language address spaces from so-called "target address spaces". llvm-svn: 338707
* Test commit accessMichael Wu2018-08-021-1/+0
| | | | llvm-svn: 338675
* [AST][4/4] Move the bit-fields from ObjCMethodDecl and ObjCContainerDecl ↵Erich Keane2018-08-011-101/+65
| | | | | | | | | | | | | | | | | into DeclContext This patch follows https://reviews.llvm.org/D49729, https://reviews.llvm.org/D49732 and https://reviews.llvm.org/D49733. Move the bits from ObjCMethodDecl and ObjCContainerDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49734 Patch By: bricci llvm-svn: 338641
* [AST][3/4] Move the bit-fields from BlockDecl, LinkageSpecDecl and ↵Erich Keane2018-08-013-52/+42
| | | | | | | | | | | | | | | | | 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-012-156/+166
| | | | | | | | | | | | | | | | | 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-012-240/+648
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r338455 "[constexpr] Support for constant evaluation of ↵Hans Wennborg2018-08-012-18/+0
| | | | | | | | | | | | | | | | __builtin_memcpy and __builtin_memmove (in non-type-punning cases)." It caused asserts during Chromium builds, see reply on the cfe-commits thread. > This is intended to permit libc++ to make std::copy etc constexpr > without sacrificing the optimization that uses memcpy on > trivially-copyable types. > > __builtin_strcpy and __builtin_wcscpy are not handled by this change. > They'd be straightforward to add, but we haven't encountered a need for > them just yet. llvm-svn: 338602
* [UnrollAndJam] Add unroll_and_jam pragma handlingDavid Green2018-08-012-5/+19
| | | | | | | | | | | | | | This adds support for the unroll_and_jam pragma, to go with the recently added unroll and jam pass. The name of the pragma is the same as is used in the Intel compiler, and most of the code works the same as for unroll. #pragma clang loop unroll_and_jam has been separated into a different patch. This part adds #pragma unroll_and_jam with an optional count, and #pragma no_unroll_and_jam to disable the transform. Differential Revision: https://reviews.llvm.org/D47267 llvm-svn: 338566
* Fix "not all control paths return a value" MSVC warning.Simon Pilgrim2018-08-011-0/+1
| | | | llvm-svn: 338502
* [AST] CastExpr: BasePathSize is not large enough.Roman Lebedev2018-08-014-16/+70
| | | | | | | | | | | | | | | | | | | | | | | | Summary: rC337815 / D49508 had to cannibalize one bit of `CastExprBitfields::BasePathSize` in order to squeeze `PartOfExplicitCast` boolean. That reduced the maximal value of `PartOfExplicitCast` from 9 bits (~512) down to 8 bits (~256). Apparently, that mattered. Too bad there weren't any tests. It caused [[ https://bugs.llvm.org/show_bug.cgi?id=38356 | PR38356 ]]. So we need to increase `PartOfExplicitCast` back at least to 9 bits, or a bit more. For obvious reasons, we can't do that in `CastExprBitfields` - that would blow up the size of every `Expr`. So we need to either just add a variable into the `CastExpr` (as done here), or use `llvm::TrailingObjects`. The latter does not seem to be straight-forward. Perhaps, that needs to be done not for the `CastExpr` itself, but for all of it's `final` children. Reviewers: rjmccall, rsmith, erichkeane Reviewed By: rjmccall Subscribers: bricci, hans, cfe-commits, waddlesplash Differential Revision: https://reviews.llvm.org/D50050 llvm-svn: 338489
* [analyzer] CallEvent: Add helper methods for obtaining the callee stack frame.Artem Dergachev2018-08-013-7/+56
| | | | | | | | | | | | Newly added methods allow reasoning about the stack frame of the call (as opposed to the stack frame on which the call was made, which was always available) - obtain the stack frame context, obtain parameter regions - even if the call is not going to be (or was not) inlined, i.e. even if the analysis has never actually entered the stack frame. Differential Revision: https://reviews.llvm.org/D49715 llvm-svn: 338474
* AMDGPU: Add clamp bit to dot builtinsKonstantin Zhuravlyov2018-08-011-7/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D50011 llvm-svn: 338471
* Avoid exposing name for range-based for '__range' variables in lifetime ↵Richard Smith2018-08-011-5/+7
| | | | | | warnings. llvm-svn: 338467
OpenPOWER on IntegriCloud