template, that member has a dependent type (even if we can see the definition
of the member of the primary template), because the array size could change in
a member specialization.
Patch by Karthik Bhat!
llvm-svn: 194740
Summary:
Similar to __FUNCTION__, MSVC exposes the name of the enclosing mangled
function name via __FUNCDNAME__. This implementation is very naive and
unoptimized, it is expected that __FUNCDNAME__ would be used rarely in
practice.
Reviewers: rnk, rsmith, thakis
CC: cfe-commits, silvas
Differential Revision: http://llvm-reviews.chandlerc.com/D2109
llvm-svn: 194181
Currently, IR generation can't handle file-scope compound literals with
non-constant initializers in C++.
Fixes PR17415 (the first crash in the bug).
(We should probably change (T){1,2,3} to use the same codepath as T{1,2,3} in
C++ eventually, given that the semantics of the latter are actually defined by
the standard.)
llvm-svn: 191719
LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.
C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.
llvm-svn: 190915
- __func__ or __FUNCTION__ returns captured statement's parent
function name, not the one compiler generated.
Differential Revision: http://llvm-reviews.chandlerc.com/D1491
Reviewed by bkramer
llvm-svn: 189219
1. We now print the return type of lambdas and return type deduced functions
as "auto". Trailing return types with decltype print the underlying type.
2. Use the lambda or block scope for the PredefinedExpr type instead of the
parent function. This fixes PR16946, a strange mismatch between type of the
expression and the actual result.
3. Verify the type in CodeGen.
4. The type for blocks is still wrong. They are numbered and the name is not
known until CodeGen.
llvm-svn: 188900
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.
llvm-svn: 188495
This is the same way GenericSelectionExpr works, and it's generally a
more consistent approach.
A large part of this patch is devoted to caching the value of the condition
of a ChooseExpr; it's needed to avoid threading an ASTContext into
IgnoreParens().
Fixes <rdar://problem/14438917>.
llvm-svn: 186738
Summary: In ARC mode, clang emits a warning if the result of an 'init' method is unused but miss cases where the method does not follows the Cocoa naming convention but is properly declared as an init family method.
CC: cfe-commits, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1163
llvm-svn: 186718
Sema needs to be able to accurately determine what will be
emitted as a constant initializer and what will not, so
we get accurate errors in C and accurate -Wglobal-constructors
warnings in C++. This makes Expr::isConstantInitializer match
CGExprConstant as closely as possible.
llvm-svn: 186464
the result of a cast-to-reference-type lifetime-extends the object to which the
reference inside the cast binds.
This requires us to look for subobject adjustments on both the inside and the
outside of the MaterializeTemporaryExpr when looking for a temporary to
lifetime-extend (which we also need for core issue 616, and possibly 1213).
llvm-svn: 184024
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
llvm-svn: 183872
which is lifetime-extended by a reference binding. An additional temporary is
created for such a bitfield access (although we have no explicit AST
representation for it).
llvm-svn: 183095
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
- 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.
llvm-svn: 181252
statement in constexpr functions. Everything which doesn't require variable
mutation is also allowed as an extension in C++11. 'void' becomes a literal
type to support constexpr functions which return 'void'.
llvm-svn: 180022
Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default initializer.
There's an additional complication here: because the default initializer can
refer to the initialized object via its 'this' pointer, we need to make sure
that 'this' points to the right thing within the evaluation.
llvm-svn: 179958
This change also makes the serialisation store the required semantics,
fixing an issue where PPC128 was always assumed when re-reading a
128-bit value.
llvm-svn: 173139
This is inspired by a number of false positives in real code, including
PR14968. I've added test cases reduced from these false positives to
test/Sema/unused-expr.c, as well as corresponding test cases that pass the
offending expressions as arguments to a no-op macro to ensure that we do warn
there.
This also removes my previous tweak from r166522/r166534, so that we warn on
unused cast expressions in macro arguments.
There were several test cases that were using -Wunused-value to test general
diagnostic emission features; I changed those to use other warnings or warn on
a macro argument expression. I stared at the test case for PR14399 for a while
with Richard Smith and we believe the new test case exercises the same
codepaths as before.
llvm-svn: 172696
Changed getLocStart() and getLocEnd() to be required for Stmts, and make
getSourceRange() optional. The default implementation for getSourceRange()
is build the range by calling getLocStart() and getLocEnd().
llvm-svn: 171067
of a member function with parenthesized declarator.
Like this test case:
class Foo {
const char *(baz)() {
return __PRETTY_FUNCTION__;
}
};
llvm-svn: 170233
