Age | Commit message (Collapse) | Author |
|
having it evaluate them. No change in functionality, but a speed up of about 5%
on some translation units in SPEC 445.gobmk.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146248 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
evaluator into constant initializer handling / IRGen. The practical consequence
of this is that the bitcast now lives in the constant's definition, rather than
in its uses.
The code in the constant expression evaluator was producing vectors of the wrong
type and size (and possibly of the wrong value for a big-endian int-to-vector
bitcast). We were getting away with this only because we don't yet support
constant-folding of any expressions which inspect vector values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145981 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
literal types, as well as derived-to-base casts for lvalues and
derived-to-virtual-base casts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144265 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expression evaluation:
- When folding a non-value-dependent expression, we may try to use the
initializer of a value-dependent variable. If that happens, give up.
- In C++98, actually check that a const, non-volatile DeclRefExpr inside an ICE
is of integral or enumeration type (a reference isn't OK!)
- In C++11, DeclRefExprs for objects of const literal type initialized with
value-dependent expressions are themselves value-dependent.
- So are references initialized with value-dependent expressions (though this
case is missing from the C++11 standard, along with many others).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144056 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143910 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions. It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.
Most of the effort here is in dealing with the various
clients of the AST. I've gone ahead and simplified the
ObjC rewriter's use of properties; other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily. Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.
I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143867 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
native representation of integers for the elements. This fixes a bunch of nastiness involving
treating wide strings as a series of bytes.
Patch by Seth Cantrell.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143417 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142695 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142012 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of a pointer.
Passing a pointer was a bad idea as it collides with the overload for void*.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141971 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141632 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141561 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141532 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140988 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is
-Immediately before the arguments: [foo first:1 second:2]
-With a space between the arguments: [foo first: 1 second: 2]
-For nullary selectors, immediately before ']': [foo release]
In such cases we infer the locations instead of storing them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140986 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140985 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
from the parser.
They are not kept in the AST yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140982 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
write barrier with captured pointer to object. // rdar://10150823
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140399 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140367 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Use ASTTemplateArgumentListInfo instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140331 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140330 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We were failing to set source locations and ranges in isUnusedResultAWarning
for CXXOperatorCallExprs, leading to an "expression result unused" warning
with absolutely no context if the expression was inside a macro.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140036 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to find the called declaration. Explicit casts can radically
change the semantics of a call, and it's no longer really a
builtin call any more than it would be a builtin call if you stored
the function pointer into a variable and called that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139659 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139466 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the lifetime of the block by copying it to the heap, or else we'll get
a dangling reference because the code working with the non-block-typed
object will not know it needs to copy.
There is some danger here, e.g. with assigning a block literal to an
unsafe variable, but, well, it's an unsafe variable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139451 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
than conversions of C pointers to ObjC pointers. In order to ensure that
we've caught every case, add asserts to CastExpr that strictly determine
which cast kind is used for which kind of bit cast.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139352 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Expr::Ignore* methods that also look through implicit casts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139303 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to look through SubstNonTypeTemplateParmExprs. Then, update the IR
generation of CallExprs to actually use CallExpr::getCalleeDecl()
rather than attempting to mimick its behavior (badly).
Fixes <rdar://problem/10063539>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139185 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
even when overloaded and user-defined. These operators are both more
valuable to warn on (due to likely typos) and extremely unlikely to be
reasonable for use to trigger side-effects.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137823 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136210 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLVM.h imports
them into the clang namespace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135852 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
As it turns out, this is my fault for not noticing this was an issue when I was looking at this a long time ago. :(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135026 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
where we have an immediate need of a retained value.
As an exception, don't do this when the call is made as the immediate
operand of a __bridge retain. This is more in the way of a workaround
than an actual guarantee, so it's acceptable to be brittle here.
rdar://problem/9504800
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134605 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type/expression/template argument/etc. is instantiation-dependent if
it somehow involves a template parameter, even if it doesn't meet the
requirements for the more common kinds of dependence (dependent type,
type-dependent expression, value-dependent expression).
When we see an instantiation-dependent type, we know we always need to
perform substitution into that instantiation-dependent type. This
keeps us from short-circuiting evaluation in places where we
shouldn't, and lets us properly implement C++0x [temp.type]p2.
In theory, this would also allow us to properly mangle
instantiation-dependent-but-not-dependent decltype types per the
Itanium C++ ABI, but we aren't quite there because we still mangle
based on the canonical type in cases like, e.g.,
template<unsigned> struct A { };
template<typename T>
void f(A<sizeof(sizeof(decltype(T() + T())))>) { }
template void f<int>(A<sizeof(sizeof(int))>);
and therefore get the wrong answer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134225 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This fixes PR10223.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134183 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Removes dead code found in the process.
Adds a test to verify that ParenListExprs do not have NULL types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133637 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133528 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expression of '?:'. Add a test case for this pattern, and also test the
code that led to the crash in a "working" case as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133523 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given
const int& r = 1.0;
The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value.
IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133521 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
use the deprecated forms of llvm::StringMap::GetOrCreateValue().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133515 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a ConstStmtVisitor. This also required adding some const iteration
support for designated initializers and making some of the getters on
the designators const.
It also made the formatting of StmtProfile.cpp rather awkward. I'm happy
to adjust any of the formatting if folks have suggestions. I've at least
fitted it all within 80 columns.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133152 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132878 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a follow-up to r132565, and should address the rest of PR9969:
Warn about cases such as
int foo(A a, bool b) {
return a + b ? 1 : 2; // user probably meant a + (b ? 1 : 2);
}
also when + is an overloaded operator call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132784 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131220 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dynamic_cast correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131177 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
callers. Shockingly enough, *there are none*!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130677 91177308-0d34-0410-b5e6-96231b3b80d8
|