summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaCast.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Allow the target field of a CK_ToUnion to be more easily recovered.John McCall2017-08-151-13/+6
| | | | llvm-svn: 310963
* [Sema][ObjC] Fix spurious -Wcast-qual warnings.Akira Hatanaka2017-08-111-1/+8
| | | | | | | | | | We do not meaningfully track object const-ness of Objective-C object types. Silence the -Wcast-qual warning that is issued when casting to or from Objective-C object types results in losing const qualification. rdar://problem/33807915 llvm-svn: 310672
* [clang] Implement -Wcast-qual for C++Roman Lebedev2017-07-031-24/+70
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This way, the behavior of that warning flag more closely resembles that of GCC. Do note that there is at least one false-negative (see FIXME in tests). Fixes PR4802. Testing: ``` ninja check-clang-sema check-clang-semacxx ``` Reviewers: dblaikie, majnemer, rnk Reviewed By: dblaikie, rnk Subscribers: mclow.lists, cfe-commits, alexfh, rnk Differential Revision: https://reviews.llvm.org/D33102 llvm-svn: 307045
* Revert "[clang] Implement -Wcast-qual for C++"Roman Lebedev2017-06-101-70/+24
| | | | | | Breaks -Werror builders. llvm-svn: 305148
* [clang] Implement -Wcast-qual for C++Roman Lebedev2017-06-101-24/+70
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This way, the behavior of that warning flag more closely resembles that of GCC. Do note that there is at least one false-negative (see FIXME in tests). Fixes PR4802. Testing: ``` ninja check-clang-sema check-clang-semacxx ``` Reviewers: dblaikie, majnemer, rnk Reviewed By: dblaikie, rnk Subscribers: cfe-commits, alexfh, rnk Differential Revision: https://reviews.llvm.org/D33102 llvm-svn: 305147
* [Sema] Make typeof(OverloadedFunctionName) not a pointer.George Burgess IV2017-05-091-1/+2
| | | | | | | | | | | | | | | | We were sometimes doing a function->pointer conversion in Sema::CheckPlaceholderExpr, which isn't the job of CheckPlaceholderExpr. So, when we saw typeof(OverloadedFunctionName), where OverloadedFunctionName referenced a name with only one function that could have its address taken, we'd give back a function pointer type instead of a function type. This is incorrect. I kept the logic for doing the function pointer conversion in resolveAndFixAddressOfOnlyViableOverloadCandidate because it was more consistent with existing ResolveAndFix* methods. llvm-svn: 302506
* [Objective-C] Miscellaneous -fobjc-weak FixesBrian Kelley2017-03-291-2/+2
| | | | | | | | | | | | | | Summary: After examining the remaining uses of LangOptions.ObjCAutoRefCount, found a some additional places to also check for ObjCWeak not covered by previous test cases. Added a test file to verify all the code paths that were changed. Reviewers: rsmith, doug.gregor, rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31007 llvm-svn: 299015
* [Objective-C] Fix "weak-unavailable" warning with -fobjc-weakBrian Kelley2017-03-291-12/+14
| | | | | | | | | | | | | | Summary: clang should produce the same errors Objective-C classes that cannot be assigned to weak pointers under both -fobjc-arc and -fobjc-weak. Check for ObjCWeak along with ObjCAutoRefCount when analyzing pointer conversions. Add an -fobjc-weak pass to the existing arc-unavailable-for-weakref test cases to verify the behavior is the same. Reviewers: rsmith, doug.gregor, rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31006 llvm-svn: 299014
* [c++1z] P0091R3: Basic support for deducing class template arguments via ↵Richard Smith2017-02-091-1/+2
| | | | | | deduction-guides. llvm-svn: 294613
* Extend -Wcast-calling-convention to warn on declarations as well as definitionsReid Kleckner2017-01-311-4/+3
| | | | | | | | | My original warning was very conservative and I never revisited the heuristics that were used. This would have caught http://crbug.com/687251 at compile time. llvm-svn: 293677
* Recommit r289979 [OpenCL] Allow disabling types and declarations associated ↵Yaxun Liu2016-12-181-1/+2
| | | | | | | | with extensions Fixed undefined behavior due to cast integer to bool in initializer list. llvm-svn: 290056
* Revert r289979 due to regressionsYaxun Liu2016-12-161-2/+1
| | | | llvm-svn: 289991
* [OpenCL] Allow disabling types and declarations associated with extensionsYaxun Liu2016-12-161-1/+2
| | | | | | | | | | | | | | | | | | Added a map to associate types and declarations with extensions. Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation. Fixed some bugs for types associated with extensions. Allow users to use pragma to declare types and functions for supported extensions, e.g. #pragma OPENCL EXTENSION the_new_extension_name : begin // declare types and functions associated with the extension here #pragma OPENCL EXTENSION the_new_extension_name : end Differential Revision: https://reviews.llvm.org/D21698 llvm-svn: 289979
* DR1295 and cleanup for P0135R1: Make our initialization code more directlyRichard Smith2016-12-091-2/+9
| | | | | | | | | | | | | | | mirror the description in the standard. Per DR1295, this means that binding a const / rvalue reference to a bit-field no longer "binds directly", and per P0135R1, this means that we materialize a temporary in reference binding after adjusting cv-qualifiers and before performing a derived-to-base cast. In C++11 onwards, this should have fixed the last case where we would materialize a temporary of the wrong type (with a subobject adjustment inside the MaterializeTemporaryExpr instead of outside), but we still have to deal with that possibility in C++98, unless we want to start using xvalues to represent materialized temporaries there too. llvm-svn: 289250
* Mass-rename the handful of error_* diagnostics to err_*.Richard Smith2016-12-021-1/+1
| | | | llvm-svn: 288545
* [Sema] Allow static_cast<T&&>(e) to check explicit conversions for ↵Eric Fiselier2016-11-031-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-reference-related types. Summary: [expr.cast.static] states: > 3. A glvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible > with “cv1 T1”. The result refers to the object or the specified base class subobject thereof. If T2 is > an inaccessible or ambiguous base class of T1, a program that necessitates such a cast is > ill-formed. > > 4. Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_- > cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t. [...] Currently when checking p3 Clang will diagnose `static_cast<T&&>(e)` as invalid if the argument is not reference compatible with `T`. However I believe the correct behavior is to also check p4 in those cases. For example: ``` double y = 42; static_cast<int&&>(y); // this should be OK. 'int&& t(y)' is well formed ``` Note that we still don't check p4 for non-reference-compatible types which are reference-related since `T&& t(e);` should never be well formed in those cases. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26231 llvm-svn: 285872
* Remove unnecessary distinction between Ref_Compatible andRichard Smith2016-10-211-1/+1
| | | | | | | Ref_Compatible_With_Added_Qualification. We always treated these two values the same way. llvm-svn: 284895
* This patch implements PR#22821.Roger Ferrer Ibanez2016-08-121-0/+3
| | | | | | | | | | | | | | | | | | Taking the address of a packed member is dangerous since the reduced alignment of the pointee is lost. This can lead to memory alignment faults in some architectures if the pointer value is dereferenced. This change adds a new warning to clang emitted when taking the address of a packed member. A packed member is either a field/data member declared as attribute((packed)) or belonging to a struct/class declared as such. The associated flag is -Waddress-of-packed-member. Conversions (either implicit or via a valid casting) to pointer types with lower or equal alignment requirements (e.g. void* or char*) will silence the warning. Differential Revision: https://reviews.llvm.org/D20561 llvm-svn: 278483
* Reverting 275417Roger Ferrer Ibanez2016-07-141-3/+0
| | | | | | This change has triggered unexpected failures. llvm-svn: 275462
* Diagnose taking address and reference binding of packed membersRoger Ferrer Ibanez2016-07-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | This patch implements PR#22821. Taking the address of a packed member is dangerous since the reduced alignment of the pointee is lost. This can lead to memory alignment faults in some architectures if the pointer value is dereferenced. This change adds a new warning to clang emitted when taking the address of a packed member. A packed member is either a field/data member declared as attribute((packed)) or belonging to a struct/class declared as such. The associated flag is -Waddress-of-packed-member. Conversions (either implicit or via a valid casting) to pointer types with lower or equal alignment requirements (e.g. void* or char*) silence the warning. This change also adds a new error diagnostic when the user attempts to bind a reference to a packed member, regardless of the alignment. Differential Revision: https://reviews.llvm.org/D20561 llvm-svn: 275417
* Use ranges to concisely express iterationDavid Majnemer2016-06-231-7/+4
| | | | | | | No functional change is intended, this should just clean things up a little. llvm-svn: 273522
* Re-commit "[Temporary] Add an ExprWithCleanups for each C++ ↵Tim Shen2016-06-211-4/+4
| | | | | | | | | | MaterializeTemporaryExpr." Since D21243 fixes relative clang-tidy tests. This reverts commit a71d9fbd41e99def9159af2b01ef6509394eaeed. llvm-svn: 273312
* Revert "[Temporary] Add an ExprWithCleanups for each C++ ↵Tim Shen2016-06-091-4/+4
| | | | | | | | | MaterializeTemporaryExpr." This reverts r272296, since there are clang-tidy failures that appear to be caused by this change. llvm-svn: 272310
* [Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr.Tim Shen2016-06-091-4/+4
| | | | | | | | | | | These ExprWithCleanups are added for holding a RunCleanupsScope not for destructor calls; rather, they are for lifetime marks. This requires ExprWithCleanups to keep a bit to indicate whether it have cleanups with side effects (e.g. dtor calls). Differential Revision: http://reviews.llvm.org/D20498 llvm-svn: 272296
* [Sema] Teach CheckPlaceholderExpr about unaddressable functions.George Burgess IV2016-06-081-17/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the following C++: ``` void foo(); void foo() __attribute__((enable_if(false, ""))); bool bar() { auto P = foo; return P == foo; } ``` We'll currently happily (and correctly) resolve `foo` to the `foo` overload without `enable_if` when assigning to `P`. However, we'll complain about an ambiguous overload on the `P == foo` line, because `Sema::CheckPlaceholderExpr` doesn't recognize that there's only one `foo` that could possibly work here. This patch teaches `Sema::CheckPlaceholderExpr` how to properly deal with such cases. Grepping for other callers of things like `Sema::ResolveAndFixSingleFunctionTemplateSpecialization`, it *looks* like this is the last place that needed to be fixed up. If I'm wrong, I'll see if there's something we can do that beats what amounts to whack-a-mole with bugs. llvm-svn: 272080
* [OpenCL] Allow explicit cast of 0 to event_t.Yaxun Liu2016-05-201-0/+16
| | | | | | | | Patch by Aaron Enye Shi. Differential Revision: http://reviews.llvm.org/D17578 llvm-svn: 270238
* Relax -Wcalling-convention-cast when casting to the default convention (cdecl)Reid Kleckner2016-05-111-1/+9
| | | | llvm-svn: 269214
* Add -Wcast-calling-convention to warn when casting away calling conventionsReid Kleckner2016-05-101-1/+88
| | | | | | | | | | | | | | | | | | | | | | Summary: This only warns on casts of the address of a function defined in the current TU. In this case, the fix is likely to be local and the warning useful. Here are some things we could experiment with in the future: - Fire on declarations as well as definitions - Limit the warning to non-void function prototypes - Limit the warning to mismatches of caller and callee cleanup CCs This warning is currently off by default while we study its usefulness. Reviewers: thakis, rtrieu Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D17348 llvm-svn: 269116
* Revert "[MSVC] PR27337: allow static_cast from private base to derived for WTL"Dmitry Polukhin2016-04-281-5/+4
| | | | | | This reverts commit r267534. llvm-svn: 267865
* [MSVC] PR27337: allow static_cast from private base to derived for WTLDmitry Polukhin2016-04-261-4/+5
| | | | | | | | | MSVC doesn't report even warning for cast from private base class to derived. Differential Revision: http://reviews.llvm.org/D19477 llvm-svn: 267534
* [MS ABI] Assign an inheritance model for the dest of a member pointer upcastDavid Majnemer2016-03-221-1/+3
| | | | | | | | | While we correctly assigned an inheritance model for the source of a member pointer upcast, we did not do so for the destination. This fixes PR27030. llvm-svn: 264065
* [Sema] Allow casting of some overloaded functionsGeorge Burgess IV2016-03-191-13/+45
| | | | | | | | | | | Some functions can't have their address taken. If we encounter an overload set where only one of the candidates can have its address taken, we should automatically select that candidate in cast expressions. Differential Revision: http://reviews.llvm.org/D17701 llvm-svn: 263887
* [Bugfix] Fix ICE on constexpr vector splat.George Burgess IV2016-01-131-0/+2
| | | | | | | | | | | | | In {CG,}ExprConstant.cpp, we weren't treating vector splats properly. This patch makes us treat splats more properly. Additionally, this patch adds a new cast kind which allows a bool->int cast to result in -1 or 0, instead of 1 or 0 (for true and false, respectively), so we can sanely model OpenCL bool->int casts in the AST. Differential Revision: http://reviews.llvm.org/D14877 llvm-svn: 257559
* Split RequireCompleteType into a function that actually requires that the typeRichard Smith2015-12-181-5/+8
| | | | | | | | | | | | | | | | | | | is complete (with an error produced if not) and a function that merely queries whether the type is complete. Either way we'll trigger instantiation if necessary, but only the former will diagnose and recover from missing module imports. The intent of this change is to prevent a class of bugs where code would call RequireCompleteType(..., 0) and then ignore the result. With modules, we must check the return value and use it to determine whether the definition of the type is visible. This also fixes a debug info quality issue: calls to isCompleteType do not trigger the emission of debug information for a type in limited-debug-info mode. This allows us to avoid emitting debug information for type definitions in more cases where we believe it is safe to do so. llvm-svn: 256049
* Wire a SourceLocation into IsDerivedFrom and move the RequireCompleteType callRichard Smith2015-12-181-8/+9
| | | | | | | | for the derived class into it. This is mostly just a cleanup, but could in principle be a bugfix if there is some codepath that reaches here and didn't previously require a complete type (I couldn't find any such codepath, though). llvm-svn: 256037
* Define weak and __weak to mean ARC-style weak references, even in MRC.John McCall2015-10-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, __weak was silently accepted and ignored in MRC mode. That makes this a potentially source-breaking change that we have to roll out cautiously. Accordingly, for the time being, actual support for __weak references in MRC is experimental, and the compiler will reject attempts to actually form such references. The intent is to eventually enable the feature by default in all non-GC modes. (It is, of course, incompatible with ObjC GC's interpretation of __weak.) If you like, you can enable this feature with -Xclang -fobjc-weak but like any -Xclang option, this option may be removed at any point, e.g. if/when it is eventually enabled by default. This patch also enables the use of the ARC __unsafe_unretained qualifier in MRC. Unlike __weak, this is being enabled immediately. Since variables are essentially __unsafe_unretained by default in MRC, the only practical uses are (1) communication and (2) changing the default behavior of by-value block capture. As an implementation matter, this means that the ObjC ownership qualifiers may appear in any ObjC language mode, and so this patch removes a number of checks for getLangOpts().ObjCAutoRefCount that were guarding the processing of these qualifiers. I don't expect this to be a significant drain on performance; it may even be faster to just check for these qualifiers directly on a type (since it's probably in a register anyway) than to do N dependent loads to grab the LangOptions. rdar://9674298 llvm-svn: 251041
* [Sema] Make `&function_with_enable_if_attrs` an errorGeorge Burgess IV2015-10-121-0/+10
| | | | | | | | | | | | | | | | | | This fixes a bug where one can take the address of a conditionally enabled function to drop its enable_if guards. For example: int foo(int a) __attribute__((enable_if(a > 0, ""))); int (*p)(int) = &foo; int result = p(-1); // compilation succeeds; calls foo(-1) Overloading logic has been updated to reflect this change, as well. Functions with enable_if attributes that are always true are still allowed to have their address taken. Differential Revision: http://reviews.llvm.org/D13607 llvm-svn: 250090
* SourceRanges are small and trivially copyable, don't them by reference.Craig Topper2015-10-041-14/+14
| | | | llvm-svn: 249259
* [MS ABI] Remove another call to RequireCompleteTypeDavid Majnemer2015-09-111-4/+0
| | | | | | | | I cannot come up with a testcase which would rely on this call to RequireCompleteType, I believe that it is superfluous given the current state of clang. llvm-svn: 247367
* Fix the perentheses location when the constructor is called on a class that ↵Olivier Goffart2015-09-041-2/+5
| | | | | | has a destructor llvm-svn: 246844
* [MSVC] Crash fix: assigning of overloaded member function pointer caused ↵Alexey Bataev2015-08-101-0/+2
| | | | | | | | | assertion Original class was not marked with inheritance attribute and it causes a crash on codegen. Differential Revision: http://reviews.llvm.org/D11828 llvm-svn: 244428
* Fix the equal-vector-size rule for reinterpret_casts in C++John McCall2015-07-231-13/+14
| | | | | | | | | | | | | to consider the storage size of the vector instead of its sizeof. In other words, ban <3 x int> to <4 x int> casts, which produced invalid IR anyway. Also, attempt to be a little more rigorous, or at least explicit, about when enums are allowed in these casts. rdar://21901132 llvm-svn: 243069
* [Sema] If lvalue to rvalue reference cast is valid don't emit diagnostic.Davide Italiano2015-07-121-2/+4
| | | | | | | | | | | | | In the test, y1 is not reference compatible to y2 and we currently assume the cast is ill-formed so we emit a diagnostic. Instead, in order to honour the standard, if y1 it's not reference-compatible to y2 then it can't be converted using a static_cast, and a reinterpret_cast should be tried instead. Richard Smith provided the correct interpretation of the standard and explanation about the subtle difference between "can't be cast" and "the cast is ill-formed". The former applies in this case. PR: 23802 llvm-svn: 241998
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | 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
* [MSVC Compatibility] Don't diagnose c-style cast from void-ptr to fn-ptrDavid Majnemer2015-06-091-1/+2
| | | | | | | | The machinery added to permit a static_cast from void-ptr to fn-ptr unintentionally gets triggered for c-style casts and function-style casts. The observable effect was a diagnostic issued inappropriately. llvm-svn: 239382
* [MSVC Compatibility] Permit static_cast from void-ptr to function-ptrDavid Majnemer2015-06-021-0/+8
| | | | | | | | | | | The MSVC 2013 and 2015 implementation of std::atomic is specialized for pointer types. The member functions are implemented using a static_cast from void-ptr to function-ptr which is not allowed in the standard. Permit this conversion if -fms-compatibility is present. This fixes PR23733. llvm-svn: 238877
* Replace getPointeeType()->isFunctionType with isMemberDataPointerTypeDavid Majnemer2015-04-241-2/+2
| | | | llvm-svn: 235682
* PR 17456Nathan Sidwell2015-01-281-0/+35
| | | | | | More helpful diagnostic on casts between unrelated class hierarchies. llvm-svn: 227371
* Don't let virtual calls and dynamic casts call Sema::MarkVTableUsed().Nico Weber2015-01-261-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang currently calls MarkVTableUsed() for classes that get their virtual methods called or that participate in a dynamic_cast. This is unnecessary, since CodeGen only emits vtables when it generates constructor, destructor, and vtt code. (*) Note that Sema::MarkVTableUsed() doesn't cause the emission of a vtable. Its main user-visible effect is that it instantiates virtual member functions of template classes, to make sure that if codegen decides to write a vtable all the entries in the vtable are defined. While this shouldn't change the behavior of codegen (other than being faster), it does make clang more permissive: virtual methods of templates (in particular destructors) end up being instantiated less often. In particular, classes that have members that are smart pointers to incomplete types will now get their implicit virtual destructor instantiated less frequently. For example, this used to not compile but does now compile: template <typename T> struct OwnPtr { ~OwnPtr() { static_assert((sizeof(T) > 0), "TypeMustBeComplete"); } }; class ScriptLoader; struct Base { virtual ~Base(); }; struct Sub : public Base { virtual void someFun() const {} OwnPtr<ScriptLoader> m_loader; }; void f(Sub *s) { s->someFun(); } The more permissive behavior matches both gcc (where this is not often observable, since in practice most things with virtual methods have a key function, and Sema::DefineUsedVTables() skips vtables for classes with key functions) and cl (which is my motivation for this change) – this fixes PR20337. See this issue and the review thread for some discussions about optimizations. This is similar to r213109 in spirit. r225761 was a prerequisite for this change. Various tests relied on "a->f()" marking a's vtable as used (in the sema sense), switch these to just construct a on the stack. This forces instantiation of the implicit constructor, which will mark the vtable as used. (*) The exception is -fapple-kext mode: In this mode, qualified calls to virtual functions (`a->Base::f()`) still go through the vtable, and since the vtable pointer off this doesn't point to Base's vtable, this needs to reference Base's vtable directly. To keep this working, keep referencing the vtable for virtual calls in apple kext mode. llvm-svn: 227073
OpenPOWER on IntegriCloud