summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateVariadic.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix crash when trying to pack-expand a GNU statement expression.Richard Smith2018-02-031-2/+12
| | | | | | | | We could in principle support such pack expansion, using techniques similar to what we do for pack expansion of lambdas, but it's not clear it's worthwhile. For now at least, cleanly reject these cases rather than crashing. llvm-svn: 324160
* Again reverting an attempt to convert the DeclSpec enums into scoped enums.Faisal Vali2018-01-011-35/+34
| | | | | | | | | | | | - reverts r321622, r321625, and r321626. - the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen. - to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change. So in short - I give up (for now at least). Sorry about the noise. llvm-svn: 321628
* [NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & ↵Faisal Vali2018-01-011-34/+35
| | | | | | | | | | | | TypeSpecifierType into scoped enums with underlying types. - Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned. Previous failed attempt - wherein I did not specify an underlying type - was the sum of: https://reviews.llvm.org/rC321614 https://reviews.llvm.org/rC321615 llvm-svn: 321622
* Revert r321614 and r321615Faisal Vali2018-01-011-35/+34
| | | | | | | | - the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration. Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;) llvm-svn: 321616
* [NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & ↵Faisal Vali2018-01-011-34/+35
| | | | | | | | TypeSpecifierType into scoped enums. llvm-svn: 321614
* Recommit "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-0/+1
| | | | | | | | This is a recommit of r312781; in some build configurations variable names are omitted, so changed the new regression test accordingly. llvm-svn: 312794
* Revert "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-1/+0
| | | | | | | The clang-with-lto-ubuntu bot didn't like the new regression test, revert while I investigate the issue. llvm-svn: 312784
* Add _Float16 as a C/C++ source language typeSjoerd Meijer2017-09-081-0/+1
| | | | | | | | | | | This adds _Float16 as a source language type, which is a 16-bit floating point type defined in C11 extension ISO/IEC TS 18661-3. In follow up patches documentation and more tests will be added. Differential Revision: https://reviews.llvm.org/D33719 llvm-svn: 312781
* Do not look through pack expansions when looking for unexpanded parameter packs.Richard Smith2017-08-151-18/+64
| | | | | | | Fixes a selection of rejects-valids when pack-expanding a lambda that itself contains a pack expansion. llvm-svn: 310972
* PR33082: Improve tracking of unexpanded parameter packs within variadic ↵Richard Smith2017-08-151-39/+87
| | | | | | generic lambdas. llvm-svn: 310946
* PR24440: Do not silently discard a fold-expression appearing as the operand ↵Richard Smith2017-02-151-0/+7
| | | | | | of a cast-expression. llvm-svn: 295224
* P0091R3: Implement basic parsing support for C++17 deduction-guides.Richard Smith2017-02-071-0/+1
| | | | | | | | | | | We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-201-11/+8
| | | | | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
* Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."Daniel Jasper2016-12-191-8/+11
| | | | | | | This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-191-11/+8
| | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
* Store decls in prototypes on the declarator instead of in the ASTReid Kleckner2016-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This saves two pointers from FunctionDecl that were being used for some rare and questionable C-only functionality. The DeclsInPrototypeScope ArrayRef was added in r151712 in order to parse this kind of C code: enum e {x, y}; int f(enum {y, x} n) { return x; // should return 1, not 0 } The challenge is that we parse 'int f(enum {y, x} n)' it its own function prototype scope that gets popped before we build the FunctionDecl for 'f'. The original change was doing two questionable things: 1. Saving all tag decls introduced in prototype scope on a TU-global Sema variable. This is problematic when you have cases like this, where 'x' and 'y' shouldn't be visible in 'f': void f(void (*fp)(enum { x, y } e)) { /* no x */ } This patch fixes that, so now 'f' can't see 'x', which is consistent with GCC. 2. Storing the decls in FunctionDecl in ActOnFunctionDeclarator so that they could be used in ActOnStartOfFunctionDef. This is just an inefficient way to move information around. The AST lives forever, but the list of non-parameter decls in prototype scope is short lived. Moving these things to the Declarator solves both of these issues. Reviewers: rsmith Subscribers: jmolloy, cfe-commits Differential Revision: https://reviews.llvm.org/D27279 llvm-svn: 289225
* PR26276: Fix detection of non-cast-expressions as operands of fold-expressions.Richard Smith2016-10-201-1/+3
| | | | llvm-svn: 284684
* Add optimization to sizeof...(X) handling: if none of parameter pack X'sRichard Smith2016-10-191-1/+58
| | | | | | | | | | | | | | | | | | | | | corresponding arguments are unexpanded pack expansions, we can compute the result without substituting them. This significantly improves the memory usage and performance of make_integer_sequence implementations that do this kind of thing: using result = integer_sequence<T, Ns ..., sizeof...(Ns) + Ns ...>; ... but note that such an implementation will still perform O(sizeof...(Ns)^2) work while building the second pack expansion (we just have a somewhat lower constant now). In principle we could get this down to linear time by caching whether the number of expansions of a pack is constant, or checking whether we're within an alias template before scanning the pack for pack expansions (since that's the only case in which we do substitutions within a dependent context at the moment), but this patch doesn't attempt that. llvm-svn: 284653
* Fix crash while parsing variable template with variadic template argumentsOlivier Goffart2016-05-261-1/+1
| | | | | | | | | | It is only a crash if the compiler optimize for this!=nullptr because LocalInstantiationScope::getPartiallySubstitutedPack checks if 'this' is null (This is crashing when clang is compiled with GCC6) Differential Revision: http://reviews.llvm.org/D20511 llvm-svn: 270845
* Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic2016-05-091-0/+1
| | | | | | | | | | | | | | | | | | This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
* Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic2016-04-151-1/+0
| | | | | | | | | | Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
* Enable support for __float128 in ClangNemanja Ivanovic2016-04-131-0/+1
| | | | | | | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
* [OpenCL] Move OpenCLImageTypes.def from clangAST to clangBasic library.Alexey Bader2016-04-131-1/+1
| | | | | | | | | | Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header". This fixes the modules build. Differential revision: http://reviews.llvm.org/D18954 Reviewers: Richard Smith, Vassil Vassilev. llvm-svn: 266180
* [OpenCL] Complete image types support.Alexey Bader2016-04-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I. Current implementation of images is not conformant to spec in the following points: 1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine: void write_image(write_only image2d_t img); kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code which is disallowed according to s6.13.14. 2. It discards access qualifier on generated code, which leads to generated code for the above example: call void @write_image(%opencl.image2d_t* %img); In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images. Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently. 3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names. 4. Default access qualifier read_only is to be added if not provided explicitly. II. This patch corrects the above points as follows: 1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type. 2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers). 3. Improves testing of images in Clang. Author: Anastasia Stulova Reviewers: bader, mgrang. Subscribers: pxli168, pekka.jaaskelainen, yaxunl. Differential Revision: http://reviews.llvm.org/D17821 llvm-svn: 265783
* Implement P0036R0: remove support for empty unary folds of +, *, |, &.Richard Smith2016-03-041-15/+0
| | | | llvm-svn: 262747
* [OpenCL] Pipe type supportXiuli Pan2016-01-091-0/+1
| | | | | | | | | | | | | | | Summary: Support for OpenCL 2.0 pipe type. This is a bug-fix version for bader's patch reviews.llvm.org/D14441 Reviewers: pekka.jaaskelainen, Anastasia Subscribers: bader, Anastasia, cfe-commits Differential Revision: http://reviews.llvm.org/D15603 llvm-svn: 257254
* Add support for GCC's '__auto_type' extension, per the GCC manual:Richard Smith2015-11-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | https://gcc.gnu.org/onlinedocs/gcc/Typeof.html Differences from the GCC extension: * __auto_type is also permitted in C++ (but only in places where it could appear in C), allowing its use in headers that might be shared across C and C++, or used from C++98 * __auto_type can be combined with a declarator, as with C++ auto (for instance, "__auto_type *p") * multiple variables can be declared in a single __auto_type declaration, with the C++ semantics (the deduced type must be the same in each case) This patch also adds a missing restriction on applying typeof to a bit-field, which GCC has historically rejected in C (due to lack of clarity as to whether the operand should be promoted). The same restriction also applies to __auto_type in C (in both GCC and Clang). This also fixes PR25449. Patch by Nicholas Allegra! llvm-svn: 252690
* PR14858: Initial support for proper sizeof... handling within alias templates.Richard Smith2015-09-231-2/+2
| | | | | | | This doesn't quite get alias template equivalence right yet, but handles the egregious cases where we would silently give the wrong answers. llvm-svn: 248431
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-2/+2
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-2/+2
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* [Sema] Factor diags with %plural. No functionality change intended.Benjamin Kramer2015-03-271-9/+4
| | | | llvm-svn: 233387
* Don't crash on an invalid trailing return type on a function before a '...'Nico Weber2014-12-301-5/+5
| | | | | | | | | | | | clang tries to produce a helpful diagnostic for the traiilng '...', but the code that r216778 added for this doesn't expect an invalid trailing return type. Add code to explicitly handle this. Having explicit code for this but not for other things looks a bit strange, but trailing return types are special in that they have a separate existence bit in addition to the type (see r158348). llvm-svn: 224974
* Update for LLVM API change to make Small(Ptr)Set::insert return ↵David Blaikie2014-11-191-1/+1
| | | | | | pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
* [c++1z] N4295: fold-expressions.Richard Smith2014-11-081-0/+105
| | | | | | | | | | | | | | | | This is a new form of expression of the form: (expr op ... op expr) where one of the exprs is a parameter pack. It expands into (expr1 op (expr2onwards op ... op expr)) (and likewise if the pack is on the right). The non-pack operand can be omitted; in that case, an empty pack gives a fallback value or an error, depending on the operator. llvm-svn: 221573
* Pass around CorrectionCandidateCallbacks as unique_ptrs soKaelyn Takata2014-10-271-4/+4
| | | | | | TypoCorrectionConsumer can keep the callback around as long as needed. llvm-svn: 220693
* Fix for PR20660, where unexpanded parameter pack in function parameter ↵Larisse Voufo2014-08-291-7/+31
| | | | | | clause causes clang to crash. llvm-svn: 216778
* Reject varargs '...' in function prototype if there are more parameters afterRichard Smith2014-08-111-0/+14
| | | | | | | | | | | it. Diagnose with recovery if it appears after a function parameter that was obviously supposed to be a parameter pack. Otherwise, warn if it immediately follows a function parameter pack, because the user most likely didn't intend to write a parameter pack followed by a C-style varargs ellipsis. This warning can be syntactically disabled by using ", ..." instead of "...". llvm-svn: 215408
* Refactoring. Remove Owned method from Sema.Nikola Smiljanic2014-05-291-2/+2
| | | | llvm-svn: 209812
* [C++11] Use 'nullptr'. Sema edition.Craig Topper2014-05-261-5/+5
| | | | llvm-svn: 209613
* Initial implementation of -modules-earch-all option, for searching for ↵John Thompson2014-04-231-1/+1
| | | | | | symbols in non-imported modules. llvm-svn: 206977
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-121-1/+1
| | | | | | class. llvm-svn: 203640
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-021-5/+5
| | | | llvm-svn: 202639
* Sort all the #include lines with LLVM's utils/sort_includes.py whichChandler Carruth2014-01-071-1/+1
| | | | | | | encodes the canonical rules for LLVM's style. I noticed this had drifted quite a bit when cleaning up LLVM, so wanted to clean up Clang as well. llvm-svn: 198686
* Remove OpenCL-specific type keywords and specifiersAlp Toker2013-12-181-8/+0
| | | | | | | | | | | | | | | This commit kills off custom type specifier and keyword handling of OpenCL C data types. Although the OpenCL spec describes them as keywords, we can handle them more elegantly as predefined types. This should provide better error correction and code completion as well as simplifying the implementation. The primary intention is however to simplify the C/C++ parser and save some packed bits on AST structures that had been extended in r170432 just for OpenCL. llvm-svn: 197578
* Refactor all diagnosing of TypoCorrections through a common function, inRichard Smith2013-08-171-8/+4
| | | | | | | preparation for teaching this function how to diagnose a correction that includes importing a module. llvm-svn: 188602
* Fix one place I missed that was memcpy'ing TypeLocs in a way that messesEli Friedman2013-06-201-0/+60
| | | | | | | | | up alignment. Fixes utilities/tuple/tuple.tuple/tuple.creation/tuple_cat.pass.cpp from the libc++ testsuite. llvm-svn: 184397
* Re-commit r183466 with a fix to make the TypeLoc casting machinery workEli Friedman2013-06-071-10/+7
| | | | | | | | | correctly in the presence of qualified types. (I had to change the unittest because it was trying to cast a QualifiedTypeLoc to TemplateSpecializationTypeLoc.) llvm-svn: 183563
* Reverts r183466: "Perform dynamic alignment computations..."Manuel Klimek2013-06-071-7/+10
| | | | | | | | | This introduces bugs in TemplateSpecializationTypeLoc's angle bracket locations. Regression test follows in a subsequent commit. llvm-svn: 183513
* Perform dynamic alignment computations so that the data in TypeLocs isEli Friedman2013-06-071-10/+7
| | | | | | | | | | | | | | | correctly aligned. Not performing such computations led to misaligned loads, which crash on some platforms and are generally bad on other platforms. The implementation of TypeLocBuilder::pushImpl is rather messy; code using TypeLocBuilder accidentally assumes that partial TypeLocs are laid out like a complete TypeLoc. As a followup, I intend to work on fixing the TypeLocBuilder API to avoid exposing partial TypeLocs; this should substantially simplify the implemementation. Fixes PR16144. llvm-svn: 183466
* First pass of semantic analysis for init-captures: check the initializer, buildRichard Smith2013-05-161-2/+6
| | | | | | | | | | | | | a FieldDecl from it, and propagate both into the closure type and the LambdaExpr. You can't do much useful with them yet -- you can't use them within the body of the lambda, because we don't have a representation for "the this of the lambda, not the this of the enclosing context". We also don't have support or a representation for a nested capture of an init-capture yet, which was intended to work despite not being allowed by the current standard wording. llvm-svn: 181985
OpenPOWER on IntegriCloud