summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX
Commit message (Collapse)AuthorAgeFilesLines
...
* Diagnose friend function template redefinitions.Serge Pavlov2018-12-062-13/+89
| | | | | | | | | | | | | | Friend function template defined in a class template becomes available if the enclosing class template is instantiated. Until the function template is used, it does not have a body, but still is considered a definition for the purpose of redeclaration checks. This change modifies redefinition check so that it can find the friend function template definitions in instantiated classes. Differential Revision: http://reviews.llvm.org/D21508 llvm-svn: 348473
* Do not check for parameters shadowing fields in function declarations.Aaron Ballman2018-12-051-2/+7
| | | | | | We would issue a false-positive diagnostic for parameters in function declarations shadowing fields; we now only issue the diagnostic on a function definition instead. llvm-svn: 348400
* Address a post-commit review comment on r348325.Erik Pilkington2018-12-051-0/+2
| | | | llvm-svn: 348388
* [Sema] Remove some conditions of a failing assertErik Pilkington2018-12-051-0/+11
| | | | | | | | | | We should have been checking that this state is consistent, but its possible for it to be filled later, so it isn't really sound to check it here anyways. Fixes llvm.org/PR39742 llvm-svn: 348325
* [WIP][Sema] Improve static_assert diagnostics for type traits.Clement Courbet2018-12-042-0/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In our codebase, `static_assert(std::some_type_trait<Ts...>::value, "msg")` (where `some_type_trait` is an std type_trait and `Ts...` is the appropriate template parameters) account for 11.2% of the `static_assert`s. In these cases, the `Ts` are typically not spelled out explicitly, e.g. `static_assert(std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value, "message");` The diagnostic when the assert fails is typically not very useful, e.g. `static_assert failed due to requirement 'std::is_same<SomeT::TypeT, typename SomeDependentT::value_type>::value' "message"` This change makes the diagnostic spell out the types explicitly , e.g. `static_assert failed due to requirement 'std::is_same<int, float>::value' "message"` See tests for more examples. After this is submitted, I intend to handle `static_assert(!std::some_type_trait<Ts...>::value, "msg")`, which is another 6.6% of static_asserts. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D54903 llvm-svn: 348239
* Fix -Wmismatched-tags to not warn on redeclarations of structs in systemRichard Smith2018-12-041-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | headers. Previously, we would only check whether the new declaration is in a system header, but that requires the user to be able to correctly guess whether a declaration in a system header is declared as a struct or a class when specializing standard library traits templates. We now entirely ignore declarations for which the warning was disabled when determining whether to warn on a tag mismatch. Also extend the diagnostic message to clarify that a) code containing such a tag mismatch is in fact valid and correct, and b) the (non-coding-style) reason to emit such a warning is that the Microsoft C++ ABI is broken and includes the tag kind in decorated names, as it seems a lot of users are confused by our diagnostic here (either not understanding why we produce it, or believing that it represents an actual language rule). llvm-svn: 348233
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-2/+3
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-3/+2
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Move AST tests into their own test directory; NFC.Aaron Ballman2018-11-305-360/+0
| | | | | | This moves everything primarily testing the functionality of -ast-dump and -ast-print into their own directory, rather than leaving the tests spread around the testing directory. llvm-svn: 348017
* Simplify the __builtin_constant_p test that was used to catch rC347417 failureFangrui Song2018-11-291-5/+2
| | | | | | | | | | | | Reviewers: rsmith, void, shafik Reviewed By: void Subscribers: kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D54964 llvm-svn: 347895
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-282-2/+11
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-271-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Resubmit this with no changes because I think the build was broken by a different diff. ----- The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp ----- Summary from Previous Diff (Still Accurate) ----- LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 llvm-svn: 347701
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-272-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Revert "[clang][slh] add attribute for speculative load hardening"Zola Bridges2018-11-271-34/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | until I figure out why the build is failing or timing out *************************** Summary: The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 This reverts commit a5b3c232d1e3613f23efbc3960f8e23ea70f2a79. (r347617) llvm-svn: 347628
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-271-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp ----- Summary from Previous Diff (Still Accurate) ----- LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 llvm-svn: 347617
* Revert "[clang][slh] add attribute for speculative load hardening"Zola Bridges2018-11-261-34/+0
| | | | | | This reverts commit 801eaf91221ba6dd6996b29ff82659ad6359e885. llvm-svn: 347588
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-261-0/+34
| | | | | | | | | | | | | | | | | | Summary: LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54555 llvm-svn: 347586
* Create a diagnostic group for ↵Sylvestre Ledru2018-11-261-1/+1
| | | | | | | | | | | | | | | | warn_call_to_pure_virtual_member_function_from_ctor_dtor, so it can be turned into an error using Werror Summary: Patch by Arnaud Bienner Reviewers: davide, rsmith, jkorous Reviewed By: jkorous Subscribers: jkorous, sylvestre.ledru, cfe-commits Differential Revision: https://reviews.llvm.org/D53807 llvm-svn: 347555
* A "constexpr" is evaluated in a constant context. Make sure this is reflectedBill Wendling2018-11-261-0/+8
| | | | | | if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347531
* isEvaluatable() implies a constant context.Bill Wendling2018-11-241-1/+2
| | | | | | | | | | Assume that we're in a constant context if we're asking if the expression can be compiled into a constant initializer. This fixes the issue where a __builtin_constant_p() in a compound literal was diagnosed as not being constant, even though it's always possible to convert the builtin into a constant. llvm-svn: 347512
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-2/+2
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Mark lambda decl as invalid if a captured variable has an invalid type.Jorge Gorbe Moya2018-11-211-0/+18
| | | | | | | This causes the compiler to crash when trying to compute a layout for the lambda closure type (see included test). llvm-svn: 347402
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-2/+2
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-2/+2
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert 347294, it turned many bots on lab.llvm.org:8011/console red.Nico Weber2018-11-201-2/+2
| | | | llvm-svn: 347314
* Use is.constant intrinsic for __builtin_constant_pBill Wendling2018-11-201-2/+2
| | | | | | | | | | | | | | | | Summary: A __builtin_constant_p may end up with a constant after inlining. Use the is.constant intrinsic if it's a variable that's in a context where it may resolve to a constant, e.g., an argument to a function after inlining. Reviewers: rsmith, shafik Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight Differential Revision: https://reviews.llvm.org/D54355 llvm-svn: 347294
* [Sema] Fix PR38987: keep end location of a direct initializer listVedant Kumar2018-11-191-0/+7
| | | | | | | | | | | | | | If PerformConstructorInitialization of a direct initializer list constructor is called while instantiating a template, it has brace locations in its BraceLoc arguments but not in the Kind argument. This reverts the hunk https://reviews.llvm.org/D41921#inline-468844. Patch by Orivej Desh! Differential Revision: https://reviews.llvm.org/D53231 llvm-svn: 347261
* [Clang][Sema]Choose a better candidate in overload function call if there is ↵Zi Xuan Wu2018-11-161-4/+4
| | | | | | | | | | | | | | | | | | | | | | a compatible vector conversion instead of ambiguous call error There are 2 function variations with vector type parameter. When we call them with argument of different vector type we would prefer to choose the variation with implicit argument conversion of compatible vector type instead of incompatible vector type. For example, typedef float __v4sf __attribute__((__vector_size__(16))); void f(vector float); void f(vector signed int); int main { __v4sf a; f(a); } Here, we'd like to choose f(vector float) but not report an ambiguous call error. Differential revision: https://reviews.llvm.org/D53417 llvm-svn: 347019
* [c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.Richard Smith2018-11-142-2/+24
| | | | | | | | | | | | | This unfortunately results in a substantial breaking change when switching to C++20, but it's not yet clear what / how much we should do about that. We may want to add a compatibility conversion from u8 string literals to const char*, similar to how C++98 provided a compatibility conversion from string literals to non-const char*, but that's not handled by this patch. The feature can be disabled in C++20 mode with -fno-char8_t. llvm-svn: 346892
* [Sema] Make sure we substitute an instantiation-dependent default template ↵Erik Pilkington2018-11-121-0/+10
| | | | | | | | | | argument Fixes llvm.org/PR39623 Differential revision: https://reviews.llvm.org/D54414 llvm-svn: 346709
* PR39628 Treat all non-zero values as 'true' in bool compound-assignmentRichard Smith2018-11-121-1/+25
| | | | | | in constant evaluation, not just odd values. llvm-svn: 346699
* Allow a double-underscore spelling of Clang attributes using double square ↵Aaron Ballman2018-11-092-2/+19
| | | | | | | | | | bracket syntax. This matches a similar behavior with GCC accepting [[gnu::__attr__]] as a alias for [[gnu::attr]] in that clang attributes can now be spelled with two leading and trailing underscores. I had always intended for this to work, but missed the critical bit. We already had an existing test in test/Preprocessor/has_attribute.cpp for [[clang::__fallthrough__]] but using that spelling would still give an "unknown attribute" diagnostic. llvm-svn: 346547
* Introduce the _Clang scoped attribute token.Aaron Ballman2018-11-091-0/+6
| | | | | | Currently, we only accept clang as the scoped attribute identifier for double square bracket attributes provided by Clang, but this has the potential to conflict with user-defined macros. To help alleviate these concerns, this introduces the _Clang scoped attribute identifier as an alias for clang. It also introduces a warning with a fixit on the off chance someone attempts to use __clang__ as the scoped attribute (which is a predefined compiler identification macro). llvm-svn: 346521
* Compound literals, enums, et al require const exprBill Wendling2018-11-091-1/+12
| | | | | | | | | | | | | | | | | | Summary: Compound literals, enums, file-scoped arrays, etc. require their initializers and size specifiers to be constant. Wrap the initializer expressions in a ConstantExpr so that we can easily check for this later on. Reviewers: rsmith, shafik Reviewed By: rsmith Subscribers: cfe-commits, jyknight, nickdesaulniers Differential Revision: https://reviews.llvm.org/D53921 llvm-svn: 346455
* [AST] Get aliased type info from an aliased TemplateSpecialization.Matt Davis2018-11-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously the TemplateSpecialization instance for 'template_alias', in the example below, returned the type info of the canonical type (int). This ignored the type alias if the template type happen to be aliased. Before this patch, the assert would trigger with an alignment of 4: ``` typedef int __attribute__(( aligned( 16 ) )) aligned_int; template < typename > using template_alias = aligned_int; static_assert( alignof( template_alias<void>) == 16, "" ); ``` This patch checks if the TemplateSpecialization type has an alias, and if so will return the type information for the aliased type, else the canonical type's info is returned (original behavior). I believe that this is the desired behavior. Reviewers: aaron.ballman, rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D54048 llvm-svn: 346146
* [coroutines] Fix fallthrough warning on try/catchBrian Gesiak2018-11-031-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The test case added in this diff would incorrectly warn that control flow may fall through without returning. Here's a standalone example: https://godbolt.org/z/dCwXEi The same program, but using `return` instead of `co_return`, does not produce a warning: https://godbolt.org/z/mVldqQ The issue was in how Clang analysis would structure its representation of the control-flow graph. Specifically, when constructing the CFG, `CFGBuilder::Visit` had special handling of a `ReturnStmt`, in which it would place object destructors in the same CFG block as a `return` statement, immediately after it. Doing so would allow the logic in `lib/Sema/AnalysisBasedWarning.cpp` `CheckFallThrough` to work properly in the program that used `return`, correctly determining that no "plain edges" preceded the exit block of the function. Because a `co_return` statement would not enjoy the same treatment when it was being built into the control-flow graph, object destructors would not be placed in the same CFG block as the `co_return`, thus resulting in a "plain edge" preceding the exit block of the function, and so the warning logic would be triggered. Add special casing for `co_return` to Clang analysis, thereby remedying the mistaken warning. Test Plan: `check-clang` Reviewers: GorNishanov, tks2103, rsmith Reviewed By: GorNishanov Subscribers: EricWF, lewissbaker, cfe-commits Differential Revision: https://reviews.llvm.org/D54075 llvm-svn: 346074
* Diagnose parameter names that shadow the names of inherited fields under ↵Aaron Ballman2018-11-021-15/+43
| | | | | | | | -Wshadow-field. This addresses PR34120. Note, unlike GCC, we take into account the accessibility of the field when deciding whether to warn or not. llvm-svn: 346041
* Fix test expectation to match reality.Richard Smith2018-10-261-3/+3
| | | | llvm-svn: 345423
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-263-10/+97
| | | | | | | | | | | | Summary: - Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof` - `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof Patch by Nicole Mazzuca! Differential Revision: https://reviews.llvm.org/D53207 llvm-svn: 345419
* [C++17] Reject shadowing of capture by parameter in lambdaNicolas Lesser2018-10-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change rejects the shadowing of a capture by a parameter in lambdas in C++17. ``` int main() { int a; auto f = [a](int a) { return a; }; } ``` results in: ``` main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity auto f = [a](int a) { return a; }; ^ main.cpp:3:13: note: variable a is explicitly captured here auto f = [a](int a) { return a; }; ^ ``` Reviewers: rsmith Reviewed By: rsmith Subscribers: lebedev.ri, erik.pilkington, cfe-commits Differential Revision: https://reviews.llvm.org/D53595 llvm-svn: 345308
* Revert "[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03"Eric Fiselier2018-10-251-21/+0
| | | | | | This reverts commit b5d8d0de744d2c212bdb17d5c5fd4447dd14dbd2. llvm-svn: 345306
* [SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03Eric Fiselier2018-10-251-0/+21
| | | | | | | | | | | | | | | | | | | | Summary: When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0). Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload. For example: https://godbolt.org/z/xXJELh This patch fixes the confusion. Reviewers: rsmith, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53508 llvm-svn: 345296
* [ms] Prevent explicit constructor name lookup if scope is missingWill Wilson2018-10-251-0/+20
| | | | | | | | | | | MicrosoftExt allows explicit constructor calls. Prevent lookup of constructor name unless the name has explicit scope. This avoids a compile-time crash due to confusing a member access for a constructor name. Test case included. All tests pass. Differential Revision: https://reviews.llvm.org/D53441 llvm-svn: 345258
* [Sema] Fix -Wcomma for C89Richard Trieu2018-10-251-116/+127
| | | | | | | | | | | | There is a small difference in the scope flags for C89 versus the other C/C++ dialects. This change ensures that the -Wcomma warning won't be duplicated or issued in the wrong location. Also, the test case is refactored into C and C++ parts, with the C++ parts guarded by a #ifdef to allow the test to run in both modes. https://bugs.llvm.org/show_bug.cgi?id=32370 llvm-svn: 345228
* Revert "[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03"Eric Fiselier2018-10-241-21/+0
| | | | | | This reverts commit 6f47cdd51341344c0e32630e19e72c94cd25f34e. llvm-svn: 345225
* [SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03Eric Fiselier2018-10-241-0/+21
| | | | | | | | | | | | | | | | | | | | Summary: When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0). Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload. For example: https://godbolt.org/z/xXJELh This patch fixes the confusion. Reviewers: rsmith, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53508 llvm-svn: 345211
* Support accepting __gnu__ as a scoped attribute namespace that aliases to gnu.Aaron Ballman2018-10-241-7/+14
| | | | | | This is useful in libstdc++ to avoid clashes with identifiers in the user's namespace. llvm-svn: 345132
* [Sema] Fix -Wcomma in dependent contextRichard Trieu2018-10-241-0/+10
| | | | | | | | | | When there is a dependent type inside a cast, the CastKind becomes CK_Dependent instead of CK_ToVoid. This fix will check that there is a dependent cast, the original type is dependent, and the target type is void to ignore the cast. https://bugs.llvm.org/show_bug.cgi?id=39375 llvm-svn: 345111
* Silence the -Wshadow warning for enumerators shadowing a type.Aaron Ballman2018-10-221-0/+7
| | | | | | Amends r344259 so that enumerators shadowing types are not diagnosed, as shadowing under those circumstances is rarely (if ever) an issue in practice. llvm-svn: 344898
* Make -Wfor-loop-analysis work with C++17Richard Trieu2018-10-201-1/+22
| | | | | | | | | For now, disable the "variable in loop condition not modified" warning to not be emitted when there is a structured binding variable in the loop condition. https://bugs.llvm.org/show_bug.cgi?id=39285 llvm-svn: 344828
OpenPOWER on IntegriCloud