summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ASTContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Use the container form llvm::sort(C, ...)Fangrui Song2018-09-301-6/+5
| | | | | | | | | There are a few leftovers of rC343147 that are not (\w+)\.begin but in the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them to use the container form in this commit. The 12 occurrences have been inspected manually for safety. llvm-svn: 343425
* [clang-cl] Fix PR38934: failing to dllexport class template member w/ ↵Hans Wennborg2018-09-141-0/+8
| | | | | | | | | | | | explicit instantiation and PCH The code in ASTContext::DeclMustBeEmitted was supposed to handle this, but didn't take into account that synthesized members such as operator= might not get marked as template specializations, because they're synthesized on the instantiation directly when handling the class-level dllexport attribute. llvm-svn: 342240
* Track definition merging on the canonical declaration even when localRichard Smith2018-09-121-4/+1
| | | | | | | | | | | | | | submodule visibility is disabled. Attempting to pick a specific declaration to make visible when the module containing the merged declaration becomes visible is error-prone, as we don't yet know which declaration we'll choose to be the definition when we are informed of the merging. This reinstates r342019, reverted in r342020. The regression previously observed after this commit was fixed in r342096. llvm-svn: 342097
* Revert r342019, "Track definition merging on the canonical declarationRichard Smith2018-09-121-1/+4
| | | | | | | | | even when [...]" Further testing has revealed that this causes build breaks during explicit module compilations. llvm-svn: 342020
* Track definition merging on the canonical declaration even when localRichard Smith2018-09-121-4/+1
| | | | | | | | | | | submodule visibility is disabled. Attempting to pick a specific declaration to make visible when the module containing the merged declaration becomes visible is error-prone, as we don't yet know which declaration we'll choose to be the definition when we are informed of the merging. llvm-svn: 342019
* Fix tracking of merged definitions when the merge target is also mergedRichard Smith2018-09-121-2/+2
| | | | | | into something else. llvm-svn: 342017
* Ensure canonical type is actually canonical.Richard Trieu2018-08-301-2/+2
| | | | | | | | | ASTContext::applyObjCProtocolQualifiers will return a canonical type when given a canonical type and an array of canonical protocols. If the protocols are not canonical then the returned type is also not canonical. Since a canonical type is needed, canonicalize the returned type before using it. This later prevents a type from having a non-canonical canonical type. llvm-svn: 341013
* Model type attributes as regular Attrs.Richard Smith2018-08-201-1/+1
| | | | | | | | | | | | | | Specifically, AttributedType now tracks a regular attr::Kind rather than having its own parallel Kind enumeration, and AttributedTypeLoc now holds an Attr* instead of holding an ad-hoc collection of Attr fields. Differential Revision: https://reviews.llvm.org/D50526 This reinstates r339623, reverted in r339638, with a fix to not fail template instantiation if we instantiate a QualType with no associated type source information and we encounter an AttributedType. llvm-svn: 340215
* [AST] Store the OwnedTagDecl as a trailing object in ElaboratedType.Bruno Ricci2018-08-161-2/+4
| | | | | | | | | | | | | | The TagDecl *OwnedTagDecl in ElaboratedType is quite commonly null (at least when parsing all of Boost, it is non-null for only about 600 of the 66k ElaboratedType). Therefore we can save a pointer in the common case by storing it as a trailing object, and storing a bit in the bit-fields of Type indicating when the pointer is null. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D50715 llvm-svn: 339862
* [OPENMP] FIx processing of declare target variables.Alexey Bataev2018-08-151-5/+6
| | | | | | | | The compiler may produce unexpected error messages/crashes when declare target variables were used. Patch fixes problems with the declarations marked as declare target to or link. llvm-svn: 339805
* [OPENMP] Fix processing of declare target construct.Alexey Bataev2018-08-141-7/+3
| | | | | | | The attribute marked as inheritable since OpenMP 5.0 supports it + additional fixes to support new functionality. llvm-svn: 339704
* Revert r339623 "Model type attributes as regular Attrs."Reid Kleckner2018-08-141-1/+1
| | | | | | | | This breaks compiling atlwin.h in Chromium. I'm sure the code is invalid in some way, but we put a lot of work into accepting it, and I'm sure rejecting it was not an intended consequence of this refactoring. :) llvm-svn: 339638
* Model type attributes as regular Attrs.Richard Smith2018-08-131-1/+1
| | | | | | | | | | Specifically, AttributedType now tracks a regular attr::Kind rather than having its own parallel Kind enumeration, and AttributedTypeLoc now holds an Attr* instead of holding an ad-hoc collection of Attr fields. Differential Revision: https://reviews.llvm.org/D50526 llvm-svn: 339623
* Enforce instantiation of template multiversion functionsErich Keane2018-08-131-1/+1
| | | | | | | | | Multiversioned member functions inside of a template type were not properly being emitted. The solution to this is to simply ensure that their bodies are correctly evaluated/assigned during template instantiation. llvm-svn: 339597
* [CodeGen] Merge equivalent block copy/helper functions.Akira Hatanaka2018-08-101-8/+11
| | | | | | | | | | | | | | | | | | | | | | | Clang generates copy and dispose helper functions for each block literal on the stack. Often these functions are equivalent for different blocks. This commit makes changes to merge equivalent copy and dispose helper functions and reduce code size. To enable merging equivalent copy/dispose functions, the captured object infomation is encoded into the helper function name. This allows IRGen to check whether an equivalent helper function has already been emitted and reuse the function instead of generating a new helper function whenever a block is defined. In addition, the helper functions are marked as linkonce_odr to enable merging helper functions that have the same name across translation units and marked as unnamed_addr to enable the linker's deduplication pass to merge functions that have different names but the same content. rdar://problem/42640608 Differential Revision: https://reviews.llvm.org/D50152 llvm-svn: 339438
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-2/+2
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* [Fixed Point Arithmetic] Fixed Point ConstantLeonard Chan2018-08-061-0/+20
| | | | | | | | | | 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
* [AST] Add individual size info for Types in -print-statsBruno Ricci2018-08-061-1/+3
| | | | | | | | This mirrors what is done for Decls and Stmts in the -print-stats output, ie instead of printing "57426 LValueReference types" we print "57426 LValueReference types, 40 each (2297040 bytes)". llvm-svn: 339024
* Try to make builtin address space declarations not uselessMatt Arsenault2018-08-021-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [OPENMP] Prevent problems with linking of the static variables.Alexey Bataev2018-07-311-21/+0
| | | | | | No need to change the linkage, we can avoid the problem using special variable. That points to the original variable and, thus, prevent some of the optimizations that might break the compilation. llvm-svn: 338399
* Remove trailing spaceFangrui Song2018-07-301-172/+172
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [ARM, AArch64]: Use unadjusted alignment when passing composites as argumentsMomchil Velikov2018-07-301-0/+31
| | | | | | | | | | | | | | | | | | The "Procedure Call Procedure Call Standard for the ARM® Architecture" (https://static.docs.arm.com/ihi0042/f/IHI0042F_aapcs.pdf), specifies that composite types are passed according to their "natural alignment", i.e. the alignment before alignment adjustment on the entire composite is applied. The same applies for AArch64 ABI. Clang, however, used the adjusted alignment. GCC already implements the ABI correctly. With this patch Clang becomes compatible with GCC and passes such arguments in accordance with AAPCS. Differential Revision: https://reviews.llvm.org/D46013 llvm-svn: 338279
* [OPENMP] Static variables on device must be externally visible.Alexey Bataev2018-07-271-0/+21
| | | | | | | Do not mark static variable as internal on the device as they must be visible from the host to be mapped correctly. llvm-svn: 338139
* DR330: when determining whether a cast casts away constness, considerRichard Smith2018-07-181-10/+11
| | | | | | | | | | | | | | | | qualifiers from all levels matching a multidimensional array. For example, this allows casting from pointer to array of array of const volatile int to pointer to const pointer to volatile pointer to int because the multidimensional array part of the source type corresponds to a part of the destination type that contains both 'const' and 'volatile'. Differential Revision: https://reviews.llvm.org/D49457 llvm-svn: 337422
* PR15730/PR16986 Allow dependently typed vector_size types.Erich Keane2018-07-131-0/+40
| | | | | | | | | | | | | | | | | As listed in the above PRs, vector_size doesn't allow dependent types/values. This patch introduces a new DependentVectorType to handle a VectorType that has a dependent size or type. In the future, ALL the vector-types should be able to create one of these to handle dependent types/sizes as well. For example, DependentSizedExtVectorType could likely be switched to just use this instead, though that is left as an exercise for the future. Differential Revision: https://reviews.llvm.org/D49045 llvm-svn: 337036
* DR330: look through array types when forming the cv-decomposition of a type.Richard Smith2018-07-111-9/+74
| | | | | | | | | | This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. llvm-svn: 336745
* Revert -r336726, which included more files than intended.Erich Keane2018-07-101-39/+0
| | | | llvm-svn: 336727
* [NFC] Switch CodeGenFunction to use value init instead of member init listsErich Keane2018-07-101-0/+39
| | | | | | | | The member init list for the sole constructor for CodeGenFunction has gotten out of hand, so this patch moves the non-parameter-dependent initializations into the member value inits. llvm-svn: 336726
* PR37979: integral promotions in C++ treat enum bit-fields like enums,Richard Smith2018-06-281-1/+9
| | | | | | | | | | | | | | | | | not like bit-fields. We used to get this right "by accident", because conversions for the selected built-in overloaded operator would convert the enum bit-field to its corresponding underlying type early. But after DR1687 that no longer happens. Technically this change should also apply to C, where bit-fields only have special promotion rules if the bit-field's declared type is _Bool, int, signed int, or unsigned int, but for GCC compatibility we only look at the bit-width and not the underlying type when performing bit-field integral promotions in C. llvm-svn: 335925
* [clang-cl] Don't emit dllexport inline functions etc. from pch files (PR37801)Hans Wennborg2018-06-251-2/+25
| | | | | | | | | | | | | | | | | | | | | | | With MSVC, PCH files are created along with an object file that needs to be linked into the final library or executable. That object file contains the code generated when building the headers. In particular, it will include definitions of inline dllexport functions, and because they are emitted in this object file, other files using the PCH do not need to emit them. See the bug for an example. This patch makes clang-cl match MSVC's behaviour in this regard, causing significant compile-time savings when building dlls using precompiled headers. For example, in a 64-bit optimized shared library build of Chromium with PCH, it reduces the binary size and compile time of stroke_opacity_custom.obj from 9315564 bytes to 3659629 bytes and 14.6 to 6.63 s. The wall-clock time of building blink_core.dll goes from 38m41s to 22m33s. ("user" time goes from 1979m to 1142m). Differential Revision: https://reviews.llvm.org/D48426 llvm-svn: 335466
* [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point LiteralsLeonard Chan2018-06-201-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal. Fixed point literals are declared using the suffixes ``` hr: short _Fract uhr: unsigned short _Fract r: _Fract ur: unsigned _Fract lr: long _Fract ulr: unsigned long _Fract hk: short _Accum uhk: unsigned short _Accum k: _Accum uk: unsigned _Accum ``` Errors are also thrown for illegal literal values ``` unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}} ``` Differential Revision: https://reviews.llvm.org/D46915 llvm-svn: 335148
* [Fixed Point Arithmetic] Addition of the remaining fixed point types and ↵Leonard Chan2018-06-141-9/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | their saturated equivalents This diff includes changes for the remaining _Fract and _Sat fixed point types. ``` signed short _Fract s_short_fract; signed _Fract s_fract; signed long _Fract s_long_fract; unsigned short _Fract u_short_fract; unsigned _Fract u_fract; unsigned long _Fract u_long_fract; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; short _Fract short_fract; _Fract fract; long _Fract long_fract; // Saturated fixed point types _Sat signed short _Accum sat_s_short_accum; _Sat signed _Accum sat_s_accum; _Sat signed long _Accum sat_s_long_accum; _Sat unsigned short _Accum sat_u_short_accum; _Sat unsigned _Accum sat_u_accum; _Sat unsigned long _Accum sat_u_long_accum; _Sat signed short _Fract sat_s_short_fract; _Sat signed _Fract sat_s_fract; _Sat signed long _Fract sat_s_long_fract; _Sat unsigned short _Fract sat_u_short_fract; _Sat unsigned _Fract sat_u_fract; _Sat unsigned long _Fract sat_u_long_fract; // Aliased saturated fixed point types _Sat short _Accum sat_short_accum; _Sat _Accum sat_accum; _Sat long _Accum sat_long_accum; _Sat short _Fract sat_short_fract; _Sat _Fract sat_fract; _Sat long _Fract sat_long_fract; ``` This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. Differential Revision: https://reviews.llvm.org/D46911 llvm-svn: 334718
* PR37680: fix faulty assertion condition.Richard Smith2018-06-061-0/+1
| | | | | | | When looking up a template name, we can find an overload set containing a function template and an unresolved non-type using declaration. llvm-svn: 334106
* Detect an incompatible VLA pointer assignmentJeremy Morse2018-06-051-2/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For pointer assignments of VLA types, Clang currently detects when array dimensions _lower_ than a variable dimension differ, and reports a warning. However it does not do the same when the _higher_ dimensions differ, a case that GCC does catch. These two pointer types int (*foo)[1][bar][3]; int (*baz)[1][2][3]; are compatible with each another, and the program is well formed if bar == 2, a matter that is the programmers problem. However the following: int (*qux)[2][2][3]; would not be compatible with either, because the upper dimension differs in size. Clang reports baz is incompatible with qux, but not that foo is incompatible with qux because it doesn't check those higher dimensions. Fix this by comparing array sizes on higher dimensions: if both are constants but unequal then report incompatibility; if either dimension is variable then we can't know either way. Differential Revision: https://reviews.llvm.org/D47628 llvm-svn: 333989
* This diff includes changes for supporting the following types.Leonard Chan2018-06-041-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches. The tests included are for asserting that we can declare these types. Fixed the test that was failing by not checking for dso_local on some targets. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333923
* Revert "This diff includes changes for supporting the following types."Leonard Chan2018-06-021-29/+0
| | | | | | | This reverts commit r333814, which fails for a test checking the bit width on ubuntu. llvm-svn: 333815
* This diff includes changes for supporting the following types.Leonard Chan2018-06-021-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | ``` // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; ``` This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches. The tests included are for asserting that we can declare these types. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333814
* Address post-commit review comments after r328731. NFC.Akira Hatanaka2018-05-151-8/+0
| | | | | | | | | | | | | | | | | | | | | | - Define a function (canPassInRegisters) that determines whether a record can be passed in registers based on language rules and target-specific ABI rules. - Set flag RecordDecl::ParamDestroyedInCallee to true in MSVC mode and remove ASTContext::isParamDestroyedInCallee, which is no longer needed. - Use the same type (unsigned) for RecordDecl's bit-field members. For more background, see the following discussions that took place on cfe-commits. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180326/223498.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180402/223688.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180409/224754.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226494.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180507/227647.html llvm-svn: 332397
* [AST] Print correct tag decl for tag specifierJoel E. Denny2018-05-141-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example, given: void fn() { struct T *p0; struct T { int i; } *p1; } -ast-print produced: void fn() { struct T { int i; } *p0; struct T { int i; } *p1; } Compiling that fails with a redefinition error. Given: void fn() { struct T *p0; struct __attribute__((deprecated)) T *p1; } -ast-print dropped the attribute. Details: For a tag specifier (that is, struct/union/class/enum used as a type specifier in a declaration) that was also a tag declaration (that is, first occurrence of the tag) or tag redeclaration (that is, later occurrence that specifies attributes or a member list), clang printed the tag specifier as either (1) the full tag definition if one existed, or (2) the first tag declaration otherwise. Redefinition errors were sometimes introduced, as in the first example above. Even when that was impossible because no member list was ever specified, attributes were sometimes lost, thus changing semantics and diagnostics, as in the second example above. This patch fixes a major culprit for these problems. It does so by creating an ElaboratedType with a new OwnedDecl member wherever an occurrence of a tag type is a (re)declaration of that tag type. PrintingPolicy's IncludeTagDefinition used to trigger printing of the member list, attributes, etc. for a tag specifier by using a tag (re)declaration selected as described above. Now, it triggers the same thing except it uses the tag (re)declaration stored in the OwnedDecl. Of course, other tooling can now make use of the new OwnedDecl as well. Also, to be more faithful to the original source, this patch suppresses printing of attributes inherited from previous declarations. Reviewed by: rsmith, aaron.ballman Differential Revision: https://reviews.llvm.org/D45463 llvm-svn: 332281
* [OpenCL] Add constant address space to __func__ in AST.Anastasia Stulova2018-05-091-0/+6
| | | | | | | | | | | | Added string literal helper function to obtain the type attributed by a constant address space. Also fixed predefind __func__ expr to use the helper to constract the string literal correctly. Differential Revision: https://reviews.llvm.org/D46049 llvm-svn: 331877
* _Atomic of empty struct shouldn't assertJF Bastien2018-05-091-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: An _Atomic of an empty struct is pretty silly. In general we just widen empty structs to hold a byte's worth of storage, and we represent size and alignment as 0 internally and let LLVM figure out what to do. For _Atomic it's a bit different: the memory model mandates concrete effects occur when atomic operations occur, so in most cases actual instructions need to get emitted. It's really not worth trying to optimize empty struct atomics by figuring out e.g. that a fence would do, even though sane compilers should do optimize atomics. Further, wg21.link/p0528 will fix C++20 atomics with padding bits so that cmpxchg on them works, which means that we'll likely need to do the zero-init song and dance for empty atomic structs anyways (and I think we shouldn't special-case this behavior to C++20 because prior standards are just broken). This patch therefore makes a minor change to r176658 "Promote atomic type sizes up to a power of two": if the width of the atomic's value type is 0, just use 1 byte for width and leave alignment as-is (since it should never be zero, and over-aligned zero-width structs are weird but fine). This fixes an assertion: (NumBits >= MIN_INT_BITS && "bitwidth too small"), function get, file ../lib/IR/Type.cpp, line 241. It seems like this has run into other assertions before (namely the unreachable Kind check in ImpCastExprToType), but I haven't reproduced that issue with tip-of-tree. <rdar://problem/39678063> Reviewers: arphaman, rjmccall Subscribers: aheejin, cfe-commits Differential Revision: https://reviews.llvm.org/D46613 llvm-svn: 331845
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-22/+22
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [C++2a] Implement operator<=> CodeGen and ExprConstantEric Fiselier2018-05-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch tackles long hanging fruit for the builtin operator<=> expressions. It is currently needs some cleanup before landing, but I want to get some initial feedback. The main changes are: * Lookup, build, and store the required standard library types and expressions in `ASTContext`. By storing them in ASTContext we don't need to store (and duplicate) the required expressions in the BinaryOperator AST nodes. * Implement [expr.spaceship] checking, including diagnosing narrowing conversions. * Implement `ExprConstant` for builtin spaceship operators. * Implement builitin operator<=> support in `CodeGenAgg`. Initially I emitted the required comparisons using `ScalarExprEmitter::VisitBinaryOperator`, but this caused the operand expressions to be emitted once for every required cmp. * Implement [builtin.over] with modifications to support the intent of P0946R0. See the note on `BuiltinOperatorOverloadBuilder::addThreeWayArithmeticOverloads` for more information about the workaround. Reviewers: rsmith, aaron.ballman, majnemer, rnk, compnerd, rjmccall Reviewed By: rjmccall Subscribers: rjmccall, rsmith, aaron.ballman, junbuml, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D45476 llvm-svn: 331677
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-34/+14
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* Implement P0482R2, support for char8_t type.Richard Smith2018-05-011-0/+6
| | | | | | | | | | | | This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a flag with the same name.) This implementation is experimental, and will be removed or revised substantially to match the proposal as it makes its way through the C++ committee. llvm-svn: 331244
* Limit types of builtins that can be redeclared.Erich Keane2018-04-161-0/+4
| | | | | | | | | | | | | | | | | | As reported here: https://bugs.llvm.org/show_bug.cgi?id=37033 Any usage of a builtin function that uses a va_list by reference will cause an assertion when redeclaring it. After discussion in the review, it was concluded that the correct way of accomplishing this fix is to make attempts to redeclare certain builtins an error. Unfortunately, doing this limitation for all builtins is likely a breaking change, so this commit simply limits it to types with custom type checking and those that take a reference. Two tests needed to be updated to make this work. Differential Revision: https://reviews.llvm.org/D45383 llvm-svn: 330160
* [XRay][llvm+clang] Consolidate attribute list filesDean Michael Berris2018-04-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This change consolidates the always/never lists that may be provided to clang to externally control which functions should be XRay instrumented by imbuing attributes. The files follow the same format as defined in https://clang.llvm.org/docs/SanitizerSpecialCaseList.html for the sanitizer blacklist. We also deprecate the existing `-fxray-instrument-always=` and `-fxray-instrument-never=` flags, in favour of `-fxray-attr-list=`. This fixes http://llvm.org/PR34721. Reviewers: echristo, vlad.tsyrklevich, eugenis Reviewed By: vlad.tsyrklevich Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D45357 llvm-svn: 329543
* Fix typos in clangAlexander Kornienko2018-04-061-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* [AST] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC).Eugene Zelenko2018-04-031-303/+292
| | | | llvm-svn: 329036
* [ObjC++] Make parameter passing and function return compatible with ObjCAkira Hatanaka2018-03-281-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud