summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX
Commit message (Collapse)AuthorAgeFilesLines
...
* Move EH spec mismatches under -fms-compatibilityReid Kleckner2019-08-273-44/+45
| | | | | | | | | | | | | | | | | | | | | -fms-extensions is intended to enable conforming language extensions and -fms-compatibility is intended to language rule relaxations, so a user could plausibly compile with -fno-ms-compatibility on Windows while still using dllexport, for example. This exception specification validation behavior has been handled as a warning since before -fms-compatibility was added in 2011. I think it's just an oversight that it hasn't been moved yet. This will help users find conformance issues in their code such as those found in _com_ptr_t as described in https://llvm.org/PR42842. Reviewers: hans Subscribers: STL_MSFT, cfe-commits Differential Revision: https://reviews.llvm.org/D66770 llvm-svn: 370087
* PR42587: diagnose unexpanded uses of a pack parameter of a genericRichard Smith2019-08-261-0/+13
| | | | | | | | | | | | | | | | | lambda from within the lambda-declarator. Instead of trying to reconstruct whether a parameter pack was declared inside a lambda (which we can't do correctly in general because we might not have attached parameters to their declaration contexts yet), track the set of parameter packs introduced in each live lambda scope, and require only those parameters to be immediately expanded when they appear inside that lambda. In passing, fix incorrect disambiguation of a lambda-expression starting with an init-capture pack in a braced-init-list. We previously incorrectly parsed that as a designated initializer. llvm-svn: 369985
* PR42513: Enter the proper DeclContext before substituting into anRichard Smith2019-08-241-3/+6
| | | | | | | | | | | | default template argument expression. We already did this for type template parameters and template template parameters, but apparently forgot to do so for non-type template parameters. This causes the substituted default argument expression to be substituted in the proper context, and in particular to properly mark its subexpressions as odr-used. llvm-svn: 369834
* Revert "PR42587: diagnose unexpanded uses of a pack parameter of a generic" ↵Richard Smith2019-08-231-8/+0
| | | | | | | | due to buildbot breakage. This reverts commit r369722. llvm-svn: 369725
* PR42587: diagnose unexpanded uses of a pack parameter of a genericRichard Smith2019-08-231-0/+8
| | | | | | lambda from within the lambda-declarator. llvm-svn: 369722
* Revert "[LifetimeAnalysis] Support more STL idioms (template forward ↵Richard Smith2019-08-222-70/+0
| | | | | | | | | | declaration and DependentNameType)" This reverts commit r369591, because it causes the formerly-reliable -Wreturn-stack-address warning to start issuing false positives. Testcase provided on the commit thread. llvm-svn: 369677
* [LifetimeAnalysis] Support more STL idioms (template forward declaration and ↵Matthias Gehre2019-08-212-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | DependentNameType) Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 369591
* [Attr] Support _attribute__ ((fallthrough))Nathan Huckleberry2019-08-202-4/+16
| | | | | | | | | | | | | | | | Summary: Fixed extraneous matches of non-NullStmt Reviewers: aaron.ballman, rsmith, efriedma, xbolva00 Reviewed By: aaron.ballman, rsmith, xbolva00 Subscribers: riccibruno, arphaman, ziangwan, ojeda, xbolva00, nickdesaulniers, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64838 llvm-svn: 369414
* Fix test where diagnostics changed in P1668 implementationErich Keane2019-08-191-6/+19
| | | | llvm-svn: 369284
* Implement P1668R1Erich Keane2019-08-191-1/+4
| | | | | | | Allow inline assembly statements in unexecuted branches of constexpr functions. llvm-svn: 369281
* [Diagnostics] Diagnose misused xor as powDavid Bolvansky2019-08-181-0/+105
| | | | | | | | | | | | | | | | | | | | Summary: Motivation: https://twitter.com/jfbastien/status/1139298419988549632 https://twitter.com/mikemx7f/status/1139335901790625793 https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=10+%5E&search=Search Reviewers: jfb, rsmith, regehr, aaron.ballman Reviewed By: aaron.ballman Subscribers: lebedev.ri, Quuxplusone, erik.pilkington, riccibruno, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63423 llvm-svn: 369217
* Allow standards-based attributes to have leading and trailing underscores.Aaron Ballman2019-08-151-1/+1
| | | | | | This gives library implementers a way to use standards-based attributes that do not conflict with user-defined macros of the same name. Attributes in C2x require this behavior normatively (C2x 6.7.11p4), but there's no reason to not have the same behavior in C++, especially given that such attributes may be used by a C library consumed by a C++ compilation. llvm-svn: 369033
* Fix handling of class member access into a vector type.Richard Smith2019-08-143-2/+26
| | | | | | | | | | | | | | | | | | | | | | When handling a member access into a non-class, non-ObjC-object type, we would perform a lookup into the surrounding scope as if for an unqualified lookup. If the member access was followed by a '<' and this lookup (or the typo-correction for it) found a template name, we'd treat the member access as naming that template. Now we treat such accesses as never naming a template if the type of the object expression is of vector type, so that vector component accesses are never misinterpreted as naming something else. This is not entirely correct, since it is in fact valid to name a template from the enclosing scope in this context, when invoking a pseudo-destructor for the vector type via an alias template, but that's very much a corner case, and this change leaves that case only as broken as the corresponding case for Objective-C types is. This incidentally adds support for dr2292, which permits a 'template' keyword at the start of a member access naming a pseudo-destructor. llvm-svn: 368940
* [Sema] Require a complete type for __builtin_bit_cast operandsErik Pilkington2019-08-121-0/+9
| | | | | | Fixes llvm.org/PR42936 llvm-svn: 368600
* cfi-icall: Allow the jump table to be optionally made non-canonical.Peter Collingbourne2019-08-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default behavior of Clang's indirect function call checker will replace the address of each CFI-checked function in the output file's symbol table with the address of a jump table entry which will pass CFI checks. We refer to this as making the jump table `canonical`. This property allows code that was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address of a function, but it comes with a couple of caveats that are especially relevant for users of cross-DSO CFI: - There is a performance and code size overhead associated with each exported function, because each such function must have an associated jump table entry, which must be emitted even in the common case where the function is never address-taken anywhere in the program, and must be used even for direct calls between DSOs, in addition to the PLT overhead. - There is no good way to take a CFI-valid address of a function written in assembly or a language not supported by Clang. The reason is that the code generator would need to insert a jump table in order to form a CFI-valid address for assembly functions, but there is no way in general for the code generator to determine the language of the function. This may be possible with LTO in the intra-DSO case, but in the cross-DSO case the only information available is the function declaration. One possible solution is to add a C wrapper for each assembly function, but these wrappers can present a significant maintenance burden for heavy users of assembly in addition to adding runtime overhead. For these reasons, we provide the option of making the jump table non-canonical with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump table is made non-canonical, symbol table entries point directly to the function body. Any instances of a function's address being taken in C will be replaced with a jump table address. This scheme does have its own caveats, however. It does end up breaking function address equality more aggressively than the default behavior, especially in cross-DSO mode which normally preserves function address equality entirely. Furthermore, it is occasionally necessary for code not compiled with ``-fsanitize=cfi-icall`` to take a function address that is valid for CFI. For example, this is necessary when a function's address is taken by assembly code and then called by CFI-checking C code. The ``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make the jump table entry of a specific function canonical so that the external code will end up taking a address for the function that will pass CFI checks. Fixes PR41972. Differential Revision: https://reviews.llvm.org/D65629 llvm-svn: 368495
* [ARM] Set default alignment to 64bitsDiogo N. Sampaio2019-08-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The maximum alignment used by ARM arch is 64bits, not 128. This could cause overaligned memory access for 128 bit neon vector that have unpredictable behaviour. This fixes: https://bugs.llvm.org/show_bug.cgi?id=42668 Reviewers: ostannard, dmgreen, srhines, danalbert, pirama, peter.smith Reviewed By: pirama, peter.smith Subscribers: phosek, thegameg, thakis, llvm-commits, carwil, peter.smith, javed.absar, kristof.beyls, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65000 llvm-svn: 368288
* Update fix-it hints for std::move warnings.Richard Trieu2019-08-082-8/+49
| | | | | | | | | | | Fix -Wpessimizing-move and -Wredundant-move when warning on initializer lists. The new fix-it hints for removing the std::move call will now also suggest removing the braces for the initializer list so that the resulting code will still be compilable. This fixes PR42832 llvm-svn: 368237
* gsl::Owner/gsl::Pointer: Add implicit annotations for some std typesMatthias Gehre2019-08-071-0/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Hard code gsl::Owner/gsl::Pointer for std types. The paper mentions some types explicitly. Generally, all containers and their iterators are covered. For iterators, we cover both the case that they are defined as an nested class or as an typedef/using. I have started to test this implementation against some real standard library implementations, namely libc++ 7.1.0, libc++ 8.0.1rc2, libstdc++ 4.6.4, libstdc++ 4.8.5, libstdc++ 4.9.4, libstdc++ 5.4.0, libstdc++ 6.5.0, libstdc++ 7.3.0, libstdc++ 8.3.0 and libstdc++ 9.1.0. The tests are currently here https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.sh https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.cpp I think due to their dependency on a standard library, they are not a good fit for clang/test/. Where else could I put them? Reviewers: gribozavr, xazax.hun Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64448 llvm-svn: 368147
* [Sema] Disable -Wbitwise-op-parentheses and -Wlogical-op-parentheses by defaultFangrui Song2019-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The -Wparentheses warnings are enabled by default in clang but they are under -Wall in gcc (gcc/c-family/c.opt). Some of the operator precedence warnings are oftentimes criticized as noise (clang: default; gcc: -Wall). If a warning is very controversial, it is probably not a good idea to enable it by default. This patch disables the rather annoying ones: -Wbitwise-op-parentheses, e.g. i & i | i -Wlogical-op-parentheses, e.g. i && i || i After this change: ``` * = enabled by default -Wall -Wparentheses -Wlogical-op-parentheses -Wlogical-not-parentheses* -Wbitwise-op-parentheses -Wshift-op-parentheses* -Woverloaded-shift-op-parentheses* -Wparentheses-equality* -Wdangling-else* ``` -Woverloaded-shift-op-parentheses is typically followed by overload resolution failure. We can instead improve the error message, and probably delete -Woverloaded-shift-op-parentheses in the future. Keep it for now because it gives some diagnostics. Reviewers: akyrtzi, jyknight, rtrieu, rsmith, aaron.ballman Reviewed By: aaron.ballman Subscribers: dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65192 llvm-svn: 367690
* [OpenCL] Allow OpenCL C style vector initialization in C++Anastasia Stulova2019-08-021-0/+8
| | | | | | | | | | | Allow creating vector literals from other vectors. float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f); float4 v = (float4)(a.s23, a.s01); Differential revision: https://reviews.llvm.org/D65286 llvm-svn: 367675
* [Sema] Actually map a variable template specialization from pattern to ↵Erik Pilkington2019-07-301-0/+29
| | | | | | | | | | | | | instantiation We were previously just using a specialization in the class template instead of creating a new specialization in the class instantiation. Fixes llvm.org/PR42779. Differential revision: https://reviews.llvm.org/D65359 llvm-svn: 367367
* Give the 'signed/unsigned wchar_t' extension a warning flag, and followRichard Smith2019-07-291-3/+5
| | | | | | GCC 9 in promoting it to an error by default. llvm-svn: 367255
* When determining whether a lambda-expression is implicitly constexpr,Richard Smith2019-07-291-0/+29
| | | | | | | | | | | | check the formal rules rather than seeing if the normal checks produce a diagnostic. This fixes the handling of C++2a extensions in lambdas in C++17 mode, as well as some corner cases in earlier language modes where we issue diagnostics for things other than not satisfying the formal constexpr requirements. llvm-svn: 367254
* Revert "[ARM] Set default alignment to 64bits"Petr Hosek2019-07-271-2/+1
| | | | | | | | | | | This reverts commit r367119. This broke several bots: http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/26891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aexception-alignment.cpp http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/245/consoleFull llvm-svn: 367166
* [ARM] Set default alignment to 64bitsSimi Pallipurath2019-07-261-1/+2
| | | | | | | | | | | | | | | | | | The maximum alignment used by ARM arch is 64bits, not 128. This could cause overaligned memory access for 128 bit neon vector that have unpredictable behaviour. This fixes: https://bugs.llvm.org/show_bug.cgi?id=42668 Patch by: Diogo Sampaio(diogo.sampaio@arm.com) Differential Revision: https://reviews.llvm.org/D65000 Change-Id: I5a62b766491f15dd51e4cfe6625929db897f67e3 llvm-svn: 367119
* Add lifetime categories attributesMatthias Gehre2019-07-251-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first part of work announced in "[RFC] Adding lifetime analysis to clang" [0], i.e. the addition of the [[gsl::Owner(T)]] and [[gsl::Pointer(T)]] attributes, which will enable user-defined types to participate in the lifetime analysis (which will be part of the next PR). The type `T` here is called "DerefType" in the paper, and denotes the type that an Owner owns and a Pointer points to. E.g. `std::vector<int>` should be annotated with `[[gsl::Owner(int)]]` and a `std::vector<int>::iterator` with `[[gsl::Pointer(int)]]`. [0] http://lists.llvm.org/pipermail/cfe-dev/2018-November/060355.html Reviewers: gribozavr Subscribers: xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63954 llvm-svn: 367040
* [c++20] P1161R3: a[b,c] is deprecated.Richard Smith2019-07-201-0/+26
| | | | llvm-svn: 366630
* Implement P1301R4, which allows specifying an optional message on the ↵Aaron Ballman2019-07-201-3/+5
| | | | | | | | [[nodiscard]] attribute. This also bumps the attribute feature test value and introduces the notion of a C++2a extension warning. llvm-svn: 366626
* Renamed and changed the wording of warn_cconv_ignoredSunil Srivastava2019-07-174-20/+20
| | | | | | | | As discussed in D64780 the wording of this warning message is being changed to say 'is not supported' instead of 'ignored', and the diag ID itself is being changed to warn_cconv_not_supported. llvm-svn: 366368
* ARM MTE stack sanitizer.Evgeniy Stepanov2019-07-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Add "memtag" sanitizer that detects and mitigates stack memory issues using armv8.5 Memory Tagging Extension. It is similar in principle to HWASan, which is a software implementation of the same idea, but there are enough differencies to warrant a new sanitizer type IMHO. It is also expected to have very different performance properties. The new sanitizer does not have a runtime library (it may grow one later, along with a "debugging" mode). Similar to SafeStack and StackProtector, the instrumentation pass (in a follow up change) will be inserted in all cases, but will only affect functions marked with the new sanitize_memtag attribute. Reviewers: pcc, hctim, vitalybuka, ostannard Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64169 llvm-svn: 366123
* [CXX] Exercise all paths through these tests.Paul Robinson2019-07-092-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D63894 llvm-svn: 365555
* Ignore trailing NullStmts in StmtExprs for GCC compatibility.Aaron Ballman2019-07-091-0/+15
| | | | | | | | Ignore trailing NullStmts in compound expressions when determining the result type and value. This is to match the GCC behavior which ignores semicolons at the end of compound expressions. Patch by Dominic Ferreira. llvm-svn: 365498
* [cxx2a] P0624R2 fix: only lambdas with no lambda-capture are ↵David Blaikie2019-07-081-30/+15
| | | | | | | | | | | | | | default-constructible and assignable. This is a fix for rG864949 which only disabled default construction and assignment for lambdas with capture-defaults, where the C++2a draft disables them for lambdas with any lambda-capture at all. Patch by Logan Smith! Differential Revision: https://reviews.llvm.org/D64058 llvm-svn: 365406
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-061-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +inf] not as [-max, +max]. Summary: Prior to r329065, we used [-max, max] as the range of representable values because LLVM's `fptrunc` did not guarantee defined behavior when truncating from a larger floating-point type to a smaller one. Now that has been fixed, we can make clang follow normal IEEE 754 semantics in this regard and take the larger range [-inf, +inf] as the range of representable values. In practice, this affects two parts of the frontend: * the constant evaluator no longer treats floating-point evaluations that result in +-inf as being undefined (because they no longer leave the range of representable values of the type) * UBSan no longer treats conversions to floating-point type that are outside the [-max, +max] range as being undefined In passing, also remove the float-divide-by-zero sanitizer from -fsanitize=undefined, on the basis that while it's undefined per C++ rules (and we disallow it in constant expressions for that reason), it is defined by Clang / LLVM / IEEE 754. Reviewers: rnk, BillyONeal Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63793 llvm-svn: 365272
* [C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington2019-07-022-0/+422
| | | | | | | | | | | | | | | | | | This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 llvm-svn: 364954
* [cxx2a] P1236R1: the validity of a left shift does not depend on theRichard Smith2019-06-252-6/+92
| | | | | | value of the LHS operand. llvm-svn: 364265
* [Sema] Improved diagnostic for qualifiers in reference bindingAnastasia Stulova2019-06-213-21/+21
| | | | | | | | | Improved wording and also simplified by using printing method from qualifiers. Differential Revision: https://reviews.llvm.org/D62914 llvm-svn: 364023
* P0840R2: support for [[no_unique_address]] attributeRichard Smith2019-06-201-0/+19
| | | | | | | | | | | | | | | | | 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
* [Sema] Diagnose addr space mismatch while constructing objectsAnastasia Stulova2019-06-201-0/+18
| | | | | | | | | | | | | | If we construct an object in some arbitrary non-default addr space it should fail unless either: - There is an implicit conversion from the address space to default /generic address space. - There is a matching ctor qualified with an address space that is either exactly matching or convertible to the address space of an object. Differential Revision: https://reviews.llvm.org/D62156 llvm-svn: 363944
* Allow copy/move assignment operator to be coroutine as per N4775Vivek Pandya2019-06-191-5/+4
| | | | | | | | | | | | This change fixes https://bugs.llvm.org/show_bug.cgi?id=40997. Reviewers: GorNishanov, rsmith Reviewed by: GorNishanov Subscribers: cfe-commits, lewissbaker, modocache, llvm-commits Differential Revision: https://reviews.llvm.org/D63381 llvm-svn: 363804
* Fix tests after r363749Aaron Puchert2019-06-181-0/+1
| | | | | | | We changed -Wmissing-prototypes there, which was used in these tests via -Weverything. llvm-svn: 363754
* Suggestions to fix -Wmissing-{prototypes,variable-declarations}Aaron Puchert2019-06-182-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: I've found that most often the proper way to fix this warning is to add `static`, because if the code otherwise compiles and links, the function or variable is apparently not needed outside of the TU. We can't provide a fix-it hint for variable declarations, because multiple VarDecls can share the same type, and if we put static in front of that, we affect all declared variables, some of which might have previous declarations. We also provide no fix-it hint for the rare case of an `extern` function definition, because that would require removing `extern` and I have no idea how to get the source location of the storage class specifier from a FunctionDecl. I believe this information is only available earlier in the AST construction from DeclSpec::getStorageClassSpecLoc(), but we don't have that here. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D59402 llvm-svn: 363749
* [clang] perform semantic checking in constant contextGauthier Harnisch2019-06-152-5/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Since the addition of __builtin_is_constant_evaluated the result of an expression can change based on whether it is evaluated in constant context. a lot of semantic checking performs evaluations with out specifying context. which can lead to wrong diagnostics. for example: ``` constexpr int i0 = (long long)__builtin_is_constant_evaluated() * (1ll << 33); //#1 constexpr int i1 = (long long)!__builtin_is_constant_evaluated() * (1ll << 33); //#2 ``` before the patch, #2 was diagnosed incorrectly and #1 wasn't diagnosed. after the patch #1 is diagnosed as it should and #2 isn't. Changes: - add a flag to Sema to passe in constant context mode. - in SemaChecking.cpp calls to Expr::Evaluate* are now done in constant context when they should. - in SemaChecking.cpp diagnostics for UB are not checked for in constant context because an error will be emitted by the constant evaluator. - in SemaChecking.cpp diagnostics for construct that cannot appear in constant context are not checked for in constant context. - in SemaChecking.cpp diagnostics on constant expression are always emitted because constant expression are always evaluated. - semantic checking for initialization of constexpr variables is now done in constant context. - adapt test that were depending on warning changes. - add test. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62009 llvm-svn: 363488
* [C++20] add Basic consteval specifierGauthier Harnisch2019-06-142-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [clang] Fixing incorrect implicit deduction guides (PR41549)Gauthier Harnisch2019-06-141-0/+15
| | | | | | | | | | | | | | | | | | | | | Summary: [[ https://bugs.llvm.org/show_bug.cgi?id=41549 | bug report ]] Before this patch, implicit deduction guides were generated from the first declaration found by lookup. With this patch implicit deduction guides are generated from the definition of the class template. Also added test that was previously failing. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits, Quuxplusone Tags: #clang Differential Revision: https://reviews.llvm.org/D63072 llvm-svn: 363361
* [clang] Don't segfault on incorrect using directive (PR41400)Gauthier Harnisch2019-06-141-0/+7
| | | | | | | | | | | | | | | | | | | Summary: this is a bugfixe for [[ https://bugs.llvm.org/show_bug.cgi?id=41400 | PR41400 ]] added nullptr check at the relevent place and test Reviewers: rsmith, riccibruno Reviewed By: rsmith Subscribers: jkooker, jkorous, riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60523 llvm-svn: 363360
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-041-3/+24
| | | | | | | | | | | | | | | | | packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. This reinstates r362358 (reverted in r362375) with a fix for an uninitialized variable use in UpdateMarkingForLValueToRValue. llvm-svn: 362531
* Fix test failure from r362435Erich Keane2019-06-031-1/+1
| | | | | | | Apparently I forgot to do an open brace in a namespace, so we get an error about an extra closing brace. llvm-svn: 362443
* Make NoThrow FunctionLike, make FunctionLike include references, fixErich Keane2019-06-031-0/+14
| | | | | | | | | | | | | prettyprint __declspec(nothrow) should work on function pointers as well as function references, so this changes it to FunctionLike. Additionally, FunctionLike needed to be modified to permit function references. Finally, the TypePrinter didn't properly print the NoThrow exception specifier, so make sure we get that right as well. llvm-svn: 362435
* Permit Exception Spec mismatch with NoThrow on inherited VirtualErich Keane2019-06-031-0/+19
| | | | | | | | | As reported here: https://bugs.llvm.org/show_bug.cgi?id=42100 This fairly common pattern ends up being an error in MinGW, so relax it in all cases to a warning. llvm-svn: 362434
OpenPOWER on IntegriCloud