compared even when one is a reference binding and the other is not
(<rdar://problem/9173984>), but the definition of an identity sequence
does not involve lvalue-to-rvalue adjustments (PR9507). Fix both
inter-related issues.
llvm-svn: 132660
return <expression> ;
in blocks with a 'void' result type, so long as <expression> has type
'void'. This follows the rules for C++ functions.
llvm-svn: 132658
with a type-dependent expression, infer the placeholder type
'Context.DependentTy' to indicate that this is just a
placeholder. Fixes PR9982 / <rdar://problem/9486685>.
llvm-svn: 132657
__builtin_astype(): Used to reinterpreted as another data type of the same size using for both scalar and vector data types.
Added test case.
llvm-svn: 132612
Warn in cases such as "x + someCondition ? 42 : 0;",
where the condition expression looks arithmetic, and has
a right-hand side that looks boolean.
This (partly) addresses http://llvm.org/bugs/show_bug.cgi?id=9969
llvm-svn: 132565
In code such as "char* volatile const j()", Clang warns that "volatile
const" will be ignored. Make it point to the first ignored qualifier,
and simplify the code a bit.
llvm-svn: 132563
Sema::RequireCompleteExprType() a bit more, setting the point of
instantiation if needed, and skipping explicit specializations entirely.
llvm-svn: 132547
diagnostic group to cover the cases where we have definitively bad
behavior: dynamic classes.
It also rips out the existing support for POD-based checking. This
didn't work well, and triggered too many false positives. I'm looking
into a possibly more principled way to warn on the fundamental buggy
construct here. POD-ness isn't the critical aspect anyways, so a clean
slate is better. This also removes some silliness from the code until
the new checks arrive.
llvm-svn: 132534
of incomplete array type, attempt to complete the array type. This was
made much easier by Chandler's addition of RequireCompleteExprType(),
which I've tweaked (slightly) to improve the consistency of the
DeclRefExpr. Fixes PR7985.
llvm-svn: 132530
the template parameter, perform the checking as a "specified" template
argument rather than a "deduced" template argument; the latter implies
stricter type checking that is not permitted for default template
arguments.
Also, cleanup our handling of substitution of explicit template
arguments for a function template. We were actually performing some
substitution of default arguments at this point!
Fixes PR10069.
llvm-svn: 132529
+keyPathsForValuesAffecting<Key> completion was mislabeled as an
instance method, and +automaticallyNotifiesObserversOf<Key> was
missing entirely. Fixes <rdar://problem/9516762>.
llvm-svn: 132452
a file was modified since the time the PCH was created.
The parser is not fit to deal with stale PCHs, too many invariants do not hold up. rdar://9530587.
llvm-svn: 132389
tools that match on the C++ ASTs. The main interface is in ASTMatchers.h,
an example implementation of a tool that removes redundant .c_str() calls
is in the example RemoveCStrCalls.cpp.
Various contributions:
Zhanyong Wan, Chandler Carruth, Marcin Kowalczyk, Wei Xu, James Dennett.
llvm-svn: 132374
class type (or array thereof), eliminating some redundant checks
(thanks Eli!) and adding some tests where the behavior differs in
C++98/03 vs. C++0x.
llvm-svn: 132218
to be careful to emit landing pads that are always prepared to handle a
cleanup path. This is correct mostly because of the fix to the LLVM
inliner, r132200.
llvm-svn: 132209
so that it looks at the initializer of a local variable of class type
(or array thereof) to determine whether it's just an implicit
invocation of the trivial default constructor. Fixes PR10034.
llvm-svn: 132191
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:
template <typename T> struct S {
static const int arr[];
static const int x;
static int f();
};
template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }
int x = S<int>::f();
We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.
This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?
llvm-svn: 132172
parameter types to be ill-formed. However, it relies on the
completeness of method parameter types when producing metadata, e.g.,
for a protocol, leading IR generating to crash in such cases.
Since there's no real way to tighten down the semantics of Objective-C
here without breaking existing code, do something safe but lame:
suppress the generation of metadata when this happens.
Fixes <rdar://problem/9123036>.
llvm-svn: 132171
makes it into a special member function. This is very bad and can lead
to all sorts of nastiness including implicit member functions violating
the One Definition Rule. This should probably be made ill-formed in a
later version of the standard, but for now we'll just warn.
llvm-svn: 132104
type that turns one type into another. This is used as the basis to
implement __underlying_type properly - with TypeSourceInfo and proper
behavior in the face of templates.
llvm-svn: 132017
that the unevaluated subexpressions of &&, ||, and ? : are not
considered when determining whether the expression is a constant
expression. Also, turn the "used in its own initializer" warning into
a runtime-behavior warning, so that it doesn't fire when a variable is
used as part of an unevaluated subexpression of its own initializer.
Fixes PR9999.
llvm-svn: 131968
through sugared types when testing for TagTypes. This was the actual
cause of the only false positive in Clang+LLVM.
Next evaluation will be over a much larger selection of code including
large amounts of open source code.
llvm-svn: 131957
issues and also add a test.
We should now handle defaulted members of templates properly. No
comment as to whether or not this also holds for templated functions,
but defaulting those is kind of insane.
llvm-svn: 131938
fixes PR9965, but we're not out of the water yet, as we do not
successfully handle out-of-line definitions, due to my utter
misunderstanding of how we manage templates.
llvm-svn: 131920
Example:
class A { public: int f(); };
class B : public A { private: using A::f; };
class C : public B { private: using B::f; };
Here, B::f is private so this should fail in Standard C++, but because B::f refers to A::f which is public MSVC accepts it.
This fixes 1 error when parsing MFC code with clang.
llvm-svn: 131896
generator will give it something sufficient. This is important because
the mid-level optimizer doesn't know what alignment is required otherwise.
llvm-svn: 131879
header. Getting it in the wrong order generated incorrect line markers in -E
mode. In the testcase from PR9861 we used to generate:
# 1 "test.c" 2
# 1 "./foobar.h" 1
# 0 "./foobar.h"
# 0 "./foobar.h" 3
# 2 "test.c" 2
now we properly produce:
# 1 "test.c" 2
# 1 "./foobar.h" 1
# 1 "./foobar.h" 3
# 2 "test.c" 2
This fixes PR9861.
llvm-svn: 131871
minor issues along the way:
- Non-type template parameters of type 'std::nullptr_t' were not
permitted.
- We didn't properly introduce built-in operators for nullptr ==,
!=, <, <=, >=, or > as candidate functions .
To my knowledge, there's only one (minor but annoying) part of nullptr
that hasn't been implemented: catching a thrown 'nullptr' as a pointer
or pointer-to-member, per C++0x [except.handle]p4.
llvm-svn: 131813
non-POD/non-trivial object throuugh a C-style varargs. The warning
itself was default-mapped to error, but can be downgraded, but we were
treating it in Sema like a hard error, silently dropping the call.
Instead, treat this problem like a warning, and do what the warning
says we do: abort at runtime. To do so, we fake up a __builtin_trap()
expression that gets evaluated as part of the argument.
llvm-svn: 131805
should use a constructor to default-initialize a
variable. InitializationSequence knows the rules for default
initialization, better. Fixes <rdar://problem/8501008>.
llvm-svn: 131796
prints the file, line, and column of a diagnostic. We currently
support Clang's normal format, MSVC, and Vi formats.
Note that we no longer change the diagnostic format based on
-fms-extensions.
Patch by Andrew Fish!
llvm-svn: 131794
Type::isUnsignedIntegerOrEnumerationType(), which are like
Type::isSignedIntegerType() and Type::isUnsignedIntegerType() but also
consider the underlying type of a C++0x scoped enumeration type.
Audited all callers to the existing functions, switching those that
need to also handle scoped enumeration types (e.g., those that deal
with constant values) over to the new functions. Fixes PR9923 /
<rdar://problem/9447851>.
llvm-svn: 131735
to a warning, since apparently libstdc++'s debug mode does this (and
we can recover safely). Add a Fix-It to insert the "inline", just for kicks.
llvm-svn: 131732
member functions by making sure that they're on the record before
checking for deletion.
Also make sure source locations are valid to avoid crashes.
Unfortunately, the declare-all-implicit-members approach is still
required in order to ensure that dependency loops do not result in
incorrectly deleting functions (since they are to be deleted at the
declaration point per the standard).
Fixes PR9917
llvm-svn: 131520
I have on that's #if 0'ed out, and I don't know why it's failing to
delete the constructor. I'd appreciate if someone familiar with access
control could look into ShouldDeleteDefaultConstructor - thanks.
llvm-svn: 131486
optimization. Make sure to require a vtable when trying to get the address
of a VTT, otherwise we would never end up emitting the VTT.
llvm-svn: 131400
operators; their semantics are guaranteed by the language.
If someone wants to argue that freestanding compiles shouldn't recognize
this, I might be convinceable.
llvm-svn: 131395
nested-name-specifier, re-evaluate the nested-name-specifier as if we
were entering that context (which we did!), so that we'll resolve a
template-id to a particular class template partial
specialization. Fixes PR9913.
llvm-svn: 131383
that the destructor body is trivial and that all member variables also have either
trivial destructors or trivial destructor bodies, we don't need to initialize the
vtable pointers since no virtual member functions will be called on the destructor.
Fixes PR9181.
llvm-svn: 131368
send if the receiver is null. Normally it's not worthwhile to check this,
but avoiding the null-initialization is nice, and this also avoids nasty
problems where the null-initialization is visible within the call because
we use an aliased result buffer. rdar://problem/9402992
llvm-svn: 131366
Go through and expand the members of bases into the encoding string (and encode the VTable as well).
Unlike gcc which expands virtual bases as many times as they appear in the
hierarchy, clang will only expand them once at the end, to reflect the actual layout.
Note that there doesn't seem to be a way to indicate in the encoding that
packing/alignment of members is different that normal, in which case
the encoding will be out-of-sync with the real layout.
If the runtime switches to just consider the size of types without
taking into account alignment, we could easily make padding explicit in the
encoding (e.g. using arrays of chars). The encoding strings would be
longer then though.
Also encode a flexible array member as array of 0 size, like gcc, not as a pointer.
llvm-svn: 131365
There are APIs, e.g. [NSValue valueWithBytes:objCType:], which use the encoding to find out
the size of an object pointed to by a pointer. Make things safer by making it illegal to @encode
incomplete types.
llvm-svn: 131364
template<class U>
struct X1 {
template<class T> void f(T*);
template<> void f(int*) { }
};
Won't be so simple. I need to think more about it.
llvm-svn: 131362
__has_extension is a function-like macro which takes the same set
of feature identifiers as __has_feature. It evaluates to 1 if the
feature is supported by Clang in the current language (either as a
language extension or a standard language feature) or 0 if not.
At the same time, add support for the C1X feature identifiers
c_generic_selections (renamed from generic_selections) and
c_static_assert, and document them.
Patch by myself and Jean-Daniel Dupas.
llvm-svn: 131308
(__m128){ p[0], p[1], p[2], p[3] }
which produces really bad code. This could be done in instcombine, but it's
probably better to do it in the front-end instead.
<rdar://problem/9424836>
llvm-svn: 131237
nested of an out-of-line declaration, only require a 'template<>'
header for each enclosing class template that hasn't been previously
specialized; previously, we were requiring 'template<>' for enclosing
class templates and members of class templates that hadn't been
previously specialized. Fixes <rdar://problem/9422013>.
llvm-svn: 131207
that they are C++0x extensions, and put them in the appropriate
group. We already support most of the semantics. Addresses
<rdar://problem/9407525>.
llvm-svn: 131153
Wait, what?
So, we run Clang (and LLVM) tests in an environment where the md5sum of the
input files becomes a component of the path. When testing the preprocessor,
the path becomes part of the output (in line directives). In this test, we
were grepping for the absence of "abc" in the output. When the stars aligned
properly, the md5sum component of the path contained "abc" and the test
failed. Oops.
llvm-svn: 131147
I've edited one diagnostic which would print "copy constructor" for copy
constructors and "constructor" for any other constructor. If anyone is
extremely enamored with this, it can be reinstated with a simple boolean
flag rather than calling getSpecialMember, which is inappropriate.
llvm-svn: 131143
the semantic context referenced by the nested-name-specifier rather
than the syntactic form of the nested-name-specifier. The previous
incarnation was based on my complete misunderstanding of C++
[temp.expl.spec]. The latest C++0x working draft clarifies the
requirements here, and this rewrite is intended to follow that.
Along the way, improve source location information in the
diagnostics. For example, if we report that a specific type needs or
doesn't need a 'template<>' header, we dig out that type in the
nested-name-specifier and highlight its range.
Fixes: PR5907, PR9421, PR8277, PR8708, PR9482, PR9668, PR9877, and
<rdar://problem/9135379>.
llvm-svn: 131138
hasTrivialDefaultConstructor() really really means it now.
Also implement a fun standards bug regarding aggregates. Doug, if you'd
like, I can un-implement that bug if you think it is truly a defect.
The bug is that non-special-member constructors are never considered
user-provided, so the following is an aggregate:
struct foo {
foo(int);
};
It's kind of bad, but the solution isn't obvious - should
struct foo {
foo (int) = delete;
};
be an aggregate or not?
Lastly, add a missing initialization to FunctionDecl.
llvm-svn: 131101
also consider whether any of the parameter types (as written, prior to
decay) are dependent. Fixes PR9880 and <rdar://problem/9408413>.
llvm-svn: 131099
bit by allowing __weak and __strong to be added/dropped as part of
implicit conversions (qualification conversions in C++). A little
history: GCC lets one add/remove/change GC qualifiers just about
anywhere, implicitly. Clang did roughly the same before, but we
recently normalized the semantics of qualifiers across the board to
get a semantics that we could reason about (yay). Unfortunately, this
tightened the screws a bit too much for GC qualifiers, where it's
common to add/remove these qualifiers at will.
Overall, we're still in better shape than we were before: we don't
permit directly changing the GC qualifier (e.g., __weak -> __strong),
so type safety is improved. More importantly, we're internally
consistent in our handling of qualifiers, and the logic that allows
adding/removing GC qualifiers (but not adding/removing address
spaces!) only touches two obvious places.
Fixes <rdar://problem/9402499>.
llvm-svn: 131065
any names that aren't in the appropriate identifier namespaces. Fixes
an embarrassing bug where we give a redefinition error due to an
Objective-C category (<rdar://problem/9388207>).
llvm-svn: 131036
Sebastian Redl