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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243069 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241998 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239382 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238877 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227073 91177308-0d34-0410-b5e6-96231b3b80d8
We know that const_cast<char *>((void)Something) is ill-formed, even if
'Something' is dependent because you can't cast from void to a pointer
type.
This fixes PR21845.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224299 91177308-0d34-0410-b5e6-96231b3b80d8
OpenCL v2.0 s6.5.5 restricts conversion of pointers to different address spaces:
- the named address spaces (__global, __local, and __private) => __generic - implicitly converted;
- __generic => named - with an explicit cast;
- named <=> named - disallowed;
- __constant <=> any other - disallowed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222834 91177308-0d34-0410-b5e6-96231b3b80d8
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211005 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207776 91177308-0d34-0410-b5e6-96231b3b80d8
If the C-style type cast is applied to the overloaded
function and the destination type is function type,
then Clang will crash with assertion failure. For example,
void foo(int);
void foo(int, int);
void bar() {
typedef void (ft)(int);
ft p = (ft)foo;
}
In this case, the overloaded function foo will be cast to
a function type, which should be considered as an error.
But, unfortunately, since the function resolution is using
canonical type, the matched function will be returned, and
result in SEGV.
This patch fixes this issue by removing the assertion and
add some error diagnostics as the one in static_cast.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206133 91177308-0d34-0410-b5e6-96231b3b80d8
Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
pointer-to-member parameter, nail down an inheritance model.
N.B. We will chose an inheritance model even if we won't ultimately
choose the template to instantiate! Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
not zero. Previously, we chose an offset of 0.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200920 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r199475 (which reverted r199416) with fixes for the
breakages.
We wouldn't lock an inheritance model if we saw a pointer-to-member
formed as a result of the address-of operator.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199482 91177308-0d34-0410-b5e6-96231b3b80d8
The MSVC ABI is rather finicky about the exact representation of it's
pointer-to-member representation. The exact position of when and where
it will go with one representation versus another appears to be when it
desires the pointer-to-member to be complete.
To properly implement this in clang, do several things:
- Give up on tracking the polymorphic nature of the class. It isn't
useful to Sema and is only pertinent when choosing CodeGen-time
details like whether the field-offset can be 0 instead of -1.
- Insist on locking-in the inheritance model when we ask our
pointer-to-member type to be complete. From there, grab the
underlying CXXRecordDecl and try to make *that* complete. Once we've
done this, we can calculate it's inheritance model and apply it using
an attribute.
N.B. My first bullet point is a lie. We will eventually care about the
specifics of whether or not a CXXRecordDecl is or is not polymorphic
because MSVC compatible mangling of such things depends on it. However,
I believe we will handle this in a rather different way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199416 91177308-0d34-0410-b5e6-96231b3b80d8
We would attempt to determine the inheritance relationship between
classes 'A' and 'B' during static_cast if we tried to convert from 'int
A::*' to 'int B::*'. However, the question "does A derive from B" is
not meaningful when 'A' isn't defined.
Handle this case by requiring that 'A' be defined.
This fixes PR18506.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199374 91177308-0d34-0410-b5e6-96231b3b80d8
We don't really need to perform semantic analysis on the dependent expression
anyway, so just call the cast dependent.
<rdar://problem/15012610>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190981 91177308-0d34-0410-b5e6-96231b3b80d8
For clarity, renamed (get/set)ParenRange as (get/set)ParenOrBraceRange
in CXXConstructExpr nodes.
Added testcase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190239 91177308-0d34-0410-b5e6-96231b3b80d8
In addition to storing more useful information in the AST, this
fixes a semantic check in template instantiation which checks whether
the l-paren location is valid.
Fixes PR16903.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188495 91177308-0d34-0410-b5e6-96231b3b80d8
This matches how we normally perform semantic analysis for other sorts
of invalid expressions: it means we don't have to reason about invalid
sub-expressions.
Fixes PR16680.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187276 91177308-0d34-0410-b5e6-96231b3b80d8
only permitted if the source object is of class type, and should materialize a
temporary for the reference to bind to.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184017 91177308-0d34-0410-b5e6-96231b3b80d8
This became allowed by accident in r131201, but triggers an assert.
That patch added an exception to allow conversion from pointers to
narrow integral types for MSVC compatibility. However, a pointer can
already be converted to bool in a civilized manner; allowing conversion
via reinterpret_cast is a bad idea.
Fixes PR16222.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183394 91177308-0d34-0410-b5e6-96231b3b80d8
This change is motivated from user feedback that some APIs use
void* as an opaque "context" object that may not really be a pointer.
Such users want an ability to turn off the warning for casts
to void* while preserving the warning for other cases.
Implements <rdar://problem/14016721>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182884 91177308-0d34-0410-b5e6-96231b3b80d8
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181252 91177308-0d34-0410-b5e6-96231b3b80d8
The suggestion was already in the text of the note; this just adds the
actual fixit and the appropriate test cases.
Patch by Alexander Zinenko!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178274 91177308-0d34-0410-b5e6-96231b3b80d8
operations (as opposed to storage only half/fp16).
Also add some semantic checks for OpenCL half types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173254 91177308-0d34-0410-b5e6-96231b3b80d8
Alexey Bataev