summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX
Commit message (Collapse)AuthorAgeFilesLines
* PR45350: Handle unsized array CXXConstructExprs in constant evaluationRichard Smith2020-05-181-0/+20
| | | | | | of array new expressions with runtime bound. (cherry picked from commit 9a7eda1bece887ca9af085d79fe6e4fb8826dcda)
* PR45000: Let Sema::SubstParmVarDecl handle default args of lambdas in ↵Aaron Puchert2020-05-061-1/+7
| | | | | | | | | | | | | | | | | | | | initializers Summary: We extend the behavior for local functions and methods of local classes to lambdas in variable initializers. The initializer is not a separate scope, but we treat it as such. We also remove the (faulty) instantiation of default arguments in TreeTransform::TransformLambdaExpr, because it doesn't do proper initialization, and if it did, we would do it twice (and thus also emit eventual errors twice). Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D76038 (cherry picked from commit f43859a099fa3587123717be941fa63ba8d0d4f2)
* [Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Saar Raz2020-03-192-2/+4
| | | | | | | | | | | | | annotates an invalid template-id TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint, in which case control flow would incorrectly flow into ParseImplicitInt. Reenter the loop in this case. Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint and changing a test case which is broken due to a separate bug (will be reported and handled separately). (cherry picked from commit 19fccc52ff2c1da1f93d9317c34769bd9bab8ac8)
* Revert "[Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Hans Wennborg2020-03-182-4/+2
| | | | | | | | | annotates an invalid template-id" We're not planning more release candidates for 10.0.0 at the moment, so reverting for now. This reverts commit 135744ce689569e7c64033bb5812572d3000239b.
* [Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Saar Raz2020-03-172-2/+4
| | | | | | | | | | | | | annotates an invalid template-id TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint, in which case control flow would incorrectly flow into ParseImplicitInt. Reenter the loop in this case. Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint and changing a test case which is broken due to a separate bug (will be reported and handled separately). (cherry picked from commit 19fccc52ff2c1da1f93d9317c34769bd9bab8ac8)
* PR45124: Don't leave behind pending cleanups when declaring implicitRichard Smith2020-03-111-0/+15
| | | | | | | | | | | | | | deduction guides. Previously if an implicit deduction guide had a default argument with a cleanup, we'd leave the 'pending cleanup' flag set after declaring the implicit guide. But it turns out that there's no reason to even substitute into the default argument when declaring an implicit deduction guide: we only need to record that the default argument exists, not what it is, since we never actually form a call to a deduction guide. (cherry picked from commit 6d894afdea433879f54e5ba07e827db006645b7b)
* Put microsoft template parameter shadow warning behind separate flag (PR44794)Hans Wennborg2020-02-261-0/+11
| | | | | | Differential revision: https://reviews.llvm.org/D75121 (cherry picked from commit 41a6612ea8afc5254e4de3aca55628d37f0be433)
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-196-36/+36
| | | | | | | | | | | | | user interface and documentation, and update __cplusplus for C++20. WG21 considers the C++20 standard to be finished (even though it still has some more steps to pass through in the ISO process). The old flag names are accepted for compatibility, as usual, and we still have lots of references to C++2a in comments and identifiers; those can be cleaned up separately. (cherry picked from commit 24ad121582454e625bdad125c90d9ac0dae948c8)
* Don't warn about missing declarations for partial template specializationsAaron Puchert2020-02-051-0/+2
| | | | | | | | | | Summary: Just like templates, they are excepted from the ODR rule. Reviewed By: aaron.ballman, rsmith Differential Revision: https://reviews.llvm.org/D68923 (cherry picked from commit 27684ae66d5545f211c0ac4393d0ba2bf3b5b47c)
* PR44786: Don't assert when profiling <=> expressions.Richard Smith2020-02-041-0/+9
| | | | (cherry picked from commit b96c6b65b93f7b3878bced2374bef747a4c3b690)
* [Sema] Remove a -Wrange warning from -WallMark de Wever2020-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | During the review of D73007 Aaron Puchert mentioned `warn_for_range_variable_always_copy` shouldn't be part of -Wall since some coding styles require `for(const auto &bar : bars)`. This warning would cause false positives for these users. Based on Aaron's proposal refactored the warnings: * -Wrange-loop-construct warns about possibly unintended constructor calls. This is part of -Wall. It contains * warn_for_range_copy: loop variable A of type B creates a copy from type C * warn_for_range_const_reference_copy: loop variable A is initialized with a value of a different type resulting in a copy * -Wrange-loop-bind-reference warns about misleading use of reference types. This is not part of -Wall. It contains * warn_for_range_variable_always_copy: loop variable A is always a copy because the range of type B does not return a reference Differential Revision: https://reviews.llvm.org/D73434 (cherry picked from commit c03349e40f21f0375278138992a32694a99c830e)
* [Concepts] Placeholder constraints and abbreviated templatesSaar Raz2020-01-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after fixing MSAN failures caused by incomplete initialization of AutoTypeLocs in TypeSpecLocFiller. Differential Revision: https://reviews.llvm.org/D65042 (cherry picked from commit b481f028144ca91c15d1db3649ce14f174259e7e)
* [Sema] Avoid Wrange-loop-analysis false positivesMark de Wever2020-01-231-0/+72
| | | | | | | | | | | | | | | | When Wrange-loop-analysis issues a diagnostic on a dependent type in a template the diagnostic may not be valid for all instantiations. Therefore the diagnostic is suppressed during the instantiation. Non dependent types still issue a diagnostic. The same can happen when using macros. Therefore the diagnostic is disabled for macros. Fixes https://bugs.llvm.org/show_bug.cgi?id=44556 Differential Revision: https://reviews.llvm.org/D73007 (cherry picked from commit 41fcd17250fa0526e4b7fd2c7df7721b0f79b683)
* PR42694 Support explicit(bool) in older language modes as an extension.Richard Smith2020-01-171-0/+1
| | | | | | | | This needs somewhat careful disambiguation, as C++2a explicit(bool) is a breaking change. We only enable it in cases where the source construct could not possibly be anything else. (cherry picked from commit 45d70806f4386adfb62b0d75949a8aad58e0576f)
* PR44514: Fix recovery from noexcept with non-convertible expressionsErich Keane2020-01-131-0/+5
| | | | | | | | | | | | We currently treat noexcept(not-convertible-to-bool) as 'none', which results in the typeloc info being a different size, and causing an assert later on in the process. In order to make recovery less destructive, replace this with noexcept(false) and a constructed 'false' expression. Bug Report: https://bugs.llvm.org/show_bug.cgi?id=44514 Differential Revision: https://reviews.llvm.org/D72621
* Implement VectorType conditional operator GNU extension.Erich Keane2020-01-131-0/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC supports the conditional operator on VectorTypes that acts as a 'select' in C++ mode. This patch implements the support. Types are converted as closely to GCC's behavior as possible, though in a few places consistency with our existing vector type support was preferred. Note that this implementation is different from the OpenCL version in a number of ways, so it unfortunately required a different implementation. First, the SEMA rules and promotion rules are significantly different. Secondly, GCC implements COND[i] != 0 ? LHS[i] : RHS[i] (where i is in the range 0- VectorSize, for each element). In OpenCL, the condition is COND[i] < 0 ? LHS[i]: RHS[i]. In the process of implementing this, it was also required to make the expression COND ? LHS : RHS type dependent if COND is type dependent, since the type is now dependent on the condition. For example: T ? 1 : 2; Is not typically type dependent, since the result can be deduced from the operands. HOWEVER, if T is a VectorType now, it could change this to a 'select' (basically a swizzle with a non-constant mask) with the 1 and 2 being promoted to vectors themselves. While this is a change, it is NOT a standards incompatible change. Based on my (and D. Gregor's, at the time of writing the code) reading of the standard, the expression is supposed to be type dependent if ANY sub-expression is type dependent. Differential Revision: https://reviews.llvm.org/D71463
* [Sema] Improve -Wrange-loop-analysis warnings.Mark de Wever2020-01-112-0/+93
| | | | | | | | | | | | | | | No longer generate a diagnostic when a small trivially copyable type is used without a reference. Before the test looked for a POD type and had no size restriction. Since the range-based for loop is only available in C++11 and POD types are trivially copyable in C++11 it's not required to test for a POD type. Since copying a large object will be expensive its size has been restricted. 64 bytes is a common size of a cache line and if the object is aligned the copy will be cheap. No performance impact testing has been done. Differential Revision: https://reviews.llvm.org/D72212
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2020-01-091-1/+23
| | | | | | | | | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers, including ranking reference bindings against non-reference bindings if they differ in non-top-level qualification conversions. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place. This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4, reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with workarounds for some overload resolution ordering problems introduced by CWG2352.
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-097-39/+30
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* Add builtins for aligning and checking alignment of pointers and integersAlex Richardson2020-01-091-0/+236
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces three new builtins (which work on both pointers and integers) that can be used instead of common bitwise arithmetic: __builtin_align_up(x, alignment), __builtin_align_down(x, alignment) and __builtin_is_aligned(x, alignment). I originally added these builtins to the CHERI fork of LLVM a few years ago to handle the slightly different C semantics that we use for CHERI [1]. Until recently these builtins (or sequences of other builtins) were required to generate correct code. I have since made changes to the default C semantics so that they are no longer strictly necessary (but using them does generate slightly more efficient code). However, based on our experience using them in various projects over the past few years, I believe that adding these builtins to clang would be useful. These builtins have the following benefit over bit-manipulation and casts via uintptr_t: - The named builtins clearly convey the semantics of the operation. While checking alignment using __builtin_is_aligned(x, 16) versus ((x & 15) == 0) is probably not a huge win in readably, I personally find __builtin_align_up(x, N) a lot easier to read than (x+(N-1))&~(N-1). - They preserve the type of the argument (including const qualifiers). When using casts via uintptr_t, it is easy to cast to the wrong type or strip qualifiers such as const. - If the alignment argument is a constant value, clang can check that it is a power-of-two and within the range of the type. Since the semantics of these builtins is well defined compared to arbitrary bit-manipulation, it is possible to add a UBSAN checker that the run-time value is a valid power-of-two. I intend to add this as a follow-up to this change. - The builtins avoids int-to-pointer casts both in C and LLVM IR. In the future (i.e. once most optimizations handle it), we could use the new llvm.ptrmask intrinsic to avoid the ptrtoint instruction that would normally be generated. - They can be used to round up/down to the next aligned value for both integers and pointers without requiring two separate macros. - In many projects the alignment operations are already wrapped in macros (e.g. roundup2 and rounddown2 in FreeBSD), so by replacing the macro implementation with a builtin call, we get improved diagnostics for many call-sites while only having to change a few lines. - Finally, the builtins also emit assume_aligned metadata when used on pointers. This can improve code generation compared to the uintptr_t casts. [1] In our CHERI compiler we have compilation mode where all pointers are implemented as capabilities (essentially unforgeable 128-bit fat pointers). In our original model, casts from uintptr_t (which is a 128-bit capability) to an integer value returned the "offset" of the capability (i.e. the difference between the virtual address and the base of the allocation). This causes problems for cases such as checking the alignment: for example, the expression `if ((uintptr_t)ptr & 63) == 0` is generally used to check if the pointer is aligned to a multiple of 64 bytes. The problem with offsets is that any pointer to the beginning of an allocation will have an offset of zero, so this check always succeeds in that case (even if the address is not correctly aligned). The same issues also exist when aligning up or down. Using the alignment builtins ensures that the address is used instead of the offset. While I have since changed the default C semantics to return the address instead of the offset when casting, this offset compilation mode can still be used by passing a command-line flag. Reviewers: rsmith, aaron.ballman, theraven, fhahn, lebedev.ri, nlopes, aqjune Reviewed By: aaron.ballman, lebedev.ri Differential Revision: https://reviews.llvm.org/D71499
* [LifetimeAnalysis] Do not forbid void deref type in gsl::Pointer/gsl::Owner ↵Gabor Horvath2020-01-071-2/+4
| | | | | | | | | | | annotations It turns out it is useful to be able to define the deref type as void. In case we have a type erased owner, we want to express that the pointee can be basically any type. It should not be unnatural to have a void deref type as we already familiar with "pointers to void". Differential Revision: https://reviews.llvm.org/D72097
* Adds -Wrange-loop-analysis to -WallMark de Wever2020-01-061-0/+1
| | | | | | | | | | This makes the range loop warnings part of -Wall. Fixes PR32823: Warn about accidental coping of data in range based for Differential Revision: https://reviews.llvm.org/D68912 Recomitted after fixing the warnings it created.
* Revert "Adds -Wrange-loop-analysis to -Wall"Mark de Wever2020-01-011-1/+0
| | | | | | The sanitizer-x86_64-linux buildbot failed to build lld with -Werror. This reverts commit d8117542ac57f6051674ca70ea14c0e0d7d9b046.
* Adds -Wrange-loop-analysis to -WallMark de Wever2020-01-011-0/+1
| | | | | | | | This makes the range loop warnings part of -Wall. Fixes PR32823: Warn about accidental coping of data in range based for Differential Revision: https://reviews.llvm.org/D68912
* Improve Wrange-loop-analyses for rvalue referenceMark de Wever2020-01-011-2/+110
| | | | | | | | | | The Wrange-loop-analyses warns if a copy is made. Suppress this warning when a temporary is bound to a rvalue reference. While fixing this issue also found a copy-paste error in test6, which is also fixed. Differential Revision: https://reviews.llvm.org/D71806
* Adds fixit hints to the -Wrange-loop-analysisMark de Wever2020-01-011-0/+44
| | | | Differential Revision: https://reviews.llvm.org/D68913
* Allow redeclaration of __declspec(uuid)Zachary Henkel2019-12-281-0/+6
| | | | | | | | | msvc allows a subsequent declaration of a uuid attribute on a struct/class. Mirror this behavior in clang-cl. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71439
* [Sema] SequenceChecker: C++17 sequencing rules for built-in operators <<, ↵Bruno Ricci2019-12-221-20/+69
| | | | | | | | | | | >>, .*, ->*, =, op= Implement the C++17 sequencing rules for the built-in operators <<, >>, .*, ->*, = and op=. Differential Revision: https://reviews.llvm.org/D58297 Reviewed By: rsmith
* [Sema] SequenceChecker: Fix handling of operator ||, && and ?:Bruno Ricci2019-12-221-8/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | The current handling of the operators ||, && and ?: has a number of false positive and false negative. The issues for operator || and && are: 1. We need to add sequencing regions for the LHS and RHS as is done for the comma operator. Not doing so causes false positives in expressions like `((a++, false) || (a++, false))` (from PR39779, see PR22197 for another example). 2. In the current implementation when the evaluation of the LHS fails, the RHS is added to a worklist to be processed later. This results in false negatives in expressions like `(a && a++) + a`. Fix these issues by introducing sequencing regions for the LHS and RHS, and by not deferring the visitation of the RHS. The issues with the ternary operator ?: are similar, with the added twist that we should not warn on expressions like `(x ? y += 1 : y += 2)` since exactly one of the 2nd and 3rd expression is going to be evaluated, but we should still warn on expressions like `(x ? y += 1 : y += 2) = y`. Differential Revision: https://reviews.llvm.org/D57747 Reviewed By: rsmith
* Check whether the destination is a complete type in a static_cast (orRichard Smith2019-12-161-10/+4
| | | | | | | | | C-style cast) to an enumeration type. We previously forgot to check this, and happened to get away with it (with bad diagnostics) only because we misclassified incomplete enumeration types as not being unscoped enumeration types. This also fixes the misclassification.
* [c++20] P1959R0: Remove support for std::*_equality.Richard Smith2019-12-164-288/+48
|
* If constant evaluation fails due to an unspecified pointer comparison,Richard Smith2019-12-162-13/+13
| | | | | produce a note saying that rather than the default "evaluation failed" note.
* [c++20] Add deprecation warnings for the expression forms deprecated by P1120R0.Richard Smith2019-12-163-178/+205
| | | | | | | | | | | | | | | | | | | This covers: * usual arithmetic conversions (comparisons, arithmetic, conditionals) between different enumeration types * usual arithmetic conversions between enums and floating-point types * comparisons between two operands of array type The deprecation warnings are on-by-default (in C++20 compilations); it seems likely that these forms will become ill-formed in C++23, so warning on them now by default seems wise. For the first two bullets, off-by-default warnings were also added for all the cases where we didn't already have warnings (covering language modes prior to C++20). These warnings are in subgroups of the existing -Wenum-conversion (except that the first case is not warned on if either enumeration type is anonymous, consistent with our existing -Wenum-conversion warnings).
* [coroutines][PR41909] Generalize fix from D62550Brian Gesiak2019-12-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In https://reviews.llvm.org/D62550 @rsmith pointed out that there are many situations in which a coroutine body statement may be transformed/rebuilt as part of a template instantiation, and my naive check whether the coroutine was a generic lambda was insufficient. This is indeed true, as I've learned by reading more of the TreeTransform code. Most transformations are written in a way that doesn't assume the resulting types are not dependent types. So the assertion in 'TransformCoroutineBodyStmt', that the promise type must no longer be dependent, is out of place. This patch removes the assertion, spruces up some code comments, and adds a test that would have failed with my naive check from https://reviews.llvm.org/D62550. Reviewers: GorNishanov, rsmith, lewissbaker Reviewed By: rsmith Subscribers: junparser, EricWF, rsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70579
* Properly compute whether statement expressions can throw, rather thanRichard Smith2019-12-151-1/+59
| | | | | | | | | conservatively assuming they always can. Also fix cases where we would not consider the computation of a VLA type when determining whether an expression can throw. We don't yet properly determine whether a VLA can throw, but no longer incorrectly claim it can never throw.
* PR44268: Fix crash if __builtin_object_size is applied to a heapRichard Smith2019-12-131-1/+7
| | | | allocation.
* [c++20] Improve phrasing of diagnostic for missing #include <compare>.Richard Smith2019-12-131-1/+15
|
* [Sema] Improve diagnostic about addr spaces for overload candidatesAnastasia Stulova2019-12-131-4/+4
| | | | | | | | | | Allow sending address spaces into diagnostics to simplify and improve error reporting. Improved wording of diagnostics for address spaces in overloading. Tags: #clang Differential Revision: https://reviews.llvm.org/D71111
* Suppress -Wwarn-unused-variables when we don't know the constructorErich Keane2019-12-121-0/+14
| | | | | | | | | | | | | | This warning is supposed to be suppressed when the constructor/destructor are non-trivial, since it might be a RAII type. However, if the type has a trivial destructor and the constructor hasn't been resolved (since it is called with dependent arguments), we were still warning. This patch suppresses the warning if the type could possibly have a be a non-trivial constructor call. Note that this does not take the arity of the constructors into consideration, so it might suppress the warning in cases where it isn't possible to call a non-trivial constructor.
* Suppress false-positive -Wuninitialized warnings in the constructor of aRichard Smith2019-12-111-0/+9
| | | | templated but non-template class.
* [c++20] Fix incorrect assumptions in checks for comparison category types.Richard Smith2019-12-092-0/+57
| | | | | | In the presence of modules, we can have multiple lookup results for the same entity, and we need to re-check for completeness each time we consider a type.
* Stop checking whether std::strong_* has ::equivalent members.Richard Smith2019-12-061-3/+3
| | | | | Any attempt to use these would be a bug, so we shouldn't even look for them.
* Fix crash if a user-defined conversion is applied in the middle of aRichard Smith2019-12-051-0/+5
| | | | rewrite of an operator in terms of operator<=>.
* Properly convert all declaration non-type template arguments whenRichard Smith2019-12-052-6/+25
| | | | | | | | | | | | forming non-type template parameter values. This reverts commit 93cc9dddd82f9e971f382ade6acf6634c5914966, which reverted commit 11d10527852b4d3ed738aa90d8bec0f398160593. We now always form `&x` when forming a pointer to a function rather than trying to use function-to-pointer decay. This matches the behavior of the old code in this case, but not the intent as described by the comments.
* Revert "Properly convert all declaration non-type template arguments when"David L. Jones2019-12-041-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 11d10527852b4d3ed738aa90d8bec0f398160593. This change is problematic with function pointer template parameters. For example, building libcxxabi with futexes (-D_LIBCXXABI_USE_FUTEX) produces this diagnostic: In file included from .../llvm-project/libcxxabi/src/cxa_guard.cpp:15: .../llvm-project/libcxxabi/src/cxa_guard_impl.h:416:54: error: address of function 'PlatformThreadID' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] has_thread_id_support(this->thread_id_address && GetThreadIDArg), ~~ ^~~~~~~~~~~~~~ .../llvm-project/libcxxabi/src/cxa_guard.cpp:38:26: note: in instantiation of member function '__cxxabiv1::(anonymous namespace)::InitByteFutex<&__cxxabiv1::(anonymous namespace)::PlatformFutexWait, &__cxxabiv1::(anonymous namespace)::PlatformFutexWake, &__cxxabiv1::(anonymous namespace)::PlatformThreadID>::InitByteFutex' requested here SelectedImplementation imp(raw_guard_object); ^ .../llvm-project/libcxxabi/src/cxa_guard_impl.h:416:54: note: prefix with the address-of operator to silence this warning has_thread_id_support(this->thread_id_address && GetThreadIDArg), ^ & 1 error generated. The diagnostic is incorrect: adding the address-of operator also fails ("cannot take the address of an rvalue of type 'uint32_t (*)()' (aka 'unsigned int (*)()')").
* Properly convert all declaration non-type template arguments whenRichard Smith2019-12-041-4/+3
| | | | forming non-type template parameter values.
* Fix crash-on-invalid-code in lambda constant evaluation.James Y Knight2019-12-041-5/+12
| | | | | | | | | | If the lambda used 'this' without without capturing it, an error was emitted, but the constant evaluator would still attempt to lookup the capture, and failing to find it, dereference a null pointer. This only happens in C++17 (as that's when lambdas were made potentially-constexpr). Therefore, I also updated the lambda-expressions.cpp test to run in both C++14 and C++17 modes.
* Reapply "Fix crash on switch conditions of non-integer types in templates"Elizabeth Andrews2019-12-031-1/+2
| | | | | | | | | | | | | | | | | | | | This patch reapplies commit 759948467ea. Patch was reverted due to a clang-tidy test fail on Windows. The test has been modified. There are no additional code changes. Patch was tested with ninja check-all on Windows and Linux. Summary of code changes: Clang currently crashes for switch statements inside a template when the condition is a non-integer field member because contextual implicit conversion is skipped when parsing the condition. This conversion is however later checked in an assert when the case statement is handled. The conversion is skipped when parsing the condition because the field member is set as type-dependent based on its containing class. This patch sets the type dependency based on the field's type instead. This patch fixes Bug 40982.
* Try to reenable -Wdeprecated-copy under -WextraDávid Bolvanský2019-11-271-0/+1
|
* Partially reland "[Diagnostics] Put "deprecated copy" warnings into ↵Dávid Bolvanský2019-11-261-0/+22
| | | | | | -Wdeprecated-copy"" But do not enable it under -Wextra until libcxx issue is solved.
OpenPOWER on IntegriCloud