- Strip off extra parens when looking for casts.
- Change the location info to point at the cast (instead of the
assignment).
For example, on
int *b;
#define a ((void*) b)
void f0() {
a = 10;
}
we now emit:
/tmp/t.c:4:3: error: assignment to cast is illegal, lvalue casts are not supported
a = 10;
^ ~
/tmp/t.c:2:12: note: instantiated from:
#define a ((void*) b)
~^~~~~~~~~~
instead of:
/tmp/t.c:4:5: error: expression is not assignable
a = 10;
~ ^
llvm-svn: 69114
its vectors based on the subobject type we're initializing and the
(unstructured) initializer list. This eliminates some malloc thrashing
when parsing initializers (from 117 vector reallocations down to 0
when parsing Cocoa.h). We can't always pre-allocate the right amount
of storage, since designated initializers can cause us to initialize
in non-predictable patterns.
llvm-svn: 67421
always, refactored the existing logic to tease apart the parser action
and the semantic analysis shared by the parser and template
instantiation.
llvm-svn: 66987
instantiation for binary operators. This change moves most of the
operator-overloading code from the parser action ActOnBinOp to a new,
parser-independent semantic checking routine CreateOverloadedBinOp.
Of particular importance is the fact that CreateOverloadedBinOp does
*not* perform any name lookup based on the current parsing context (it
doesn't take a Scope*), since it has to be usable during template
instantiation, when there is no scope information. Rather, it takes a
pre-computed set of functions that are visible from the context or via
argument-dependent lookup, and adds to that set any member operators
and built-in operator candidates. The set of functions is computed in
the parser action ActOnBinOp based on the current context (both
operator name lookup and argument-dependent lookup). Within a
template, the set computed by ActOnBinOp is saved within the
type-dependent AST node and is augmented with the results of
argument-dependent name lookup at instantiation time (see
TemplateExprInstantiator::VisitCXXOperatorCallExpr).
Sadly, we can't fully test this yet. I'll follow up with template
instantiation for sizeof so that the real fun can begin.
llvm-svn: 66923
normal expression, and change Evaluate and IRGen to evaluate it like a
normal expression. This simplifies the code significantly, and fixes
PR3396.
llvm-svn: 65622
is a rather big change, but I think this is the direction we want to go;
the code is significantly shorter now, and it doesn't duplicate Evaluate
code. There shouldn't be any visible changes as far as I know.
There has been some movement towards putting ICE handling into
Evaluate (for example, VerifyIntegerConstantExpression uses Evaluate
instead of isICE). This patch is sort of the opposite of the approach,
making ICE handling work without Evaluate being aware of it. I think
this approach is better because it separates the code that does the
constant evaluation from code that's calculating a rather
arbitrary predicate.
The one thing I don't really like about this patch is that
the handling of commas in C99 complicates it signficantly. (Seriously,
what was the standards committee thinking when they wrote that
part?) I think I've come up with a decent approach, but it doesn't feel
ideal. I might add some way to check for evaluated commas from Evaluate
in a subsequent patch; that said, it might not be worth bothering.
llvm-svn: 65524
the various PPTokens that are pasted together to make it. In the course
of working on this, I discovered ParseObjCStringLiteral which needs some
work. I'll tackle it next.
llvm-svn: 64892
- This idiom ensures that the result will have the right width and
type.
- Tested on most of x86_64/llvm-test to satisfy my paranoia.
- This fixes at least the following bugs:
o UnaryTypeTraitExpr wasn't setting the width correctly.
o Arithmetic on _Bool wasn't setting the width correctly.
And probably a number more.
llvm-svn: 64864
Doug: please verify that it is expected that LastIdx can be less that
NumInits. And perhaps add a comment so that Chris doesn't break your
code. :)
llvm-svn: 64688
about, whether they are builtins or not. Use this to add the
appropriate "format" attribute to NSLog, NSLogv, asprintf, and
vasprintf, and to translate builtin attributes (from Builtins.def)
into actual attributes on the function declaration.
Use the "printf" format attribute on function declarations to
determine whether we should do format string checking, rather than
looking at an ad hoc list of builtins and "known" function names.
Be a bit more careful about when we consider a function a "builtin" in
C++.
llvm-svn: 64561
1) implement parser and sema support for reading and verifying attribute(warnunusedresult).
2) rename hasLocalSideEffect to isUnusedResultAWarning, inverting the sense
of its result.
3) extend isUnusedResultAWarning to directly return the loc and range
info that should be reported to the user. Make it substantially more
precise in some cases than what was previously reported.
4) teach isUnusedResultAWarning about CallExpr to decls that are
pure/const/warnunusedresult, fixing a fixme.
5) change warn_attribute_wrong_decl_type to not pass in english strings, instead,
pass in integers and use %select.
llvm-svn: 64543
etc.) when we perform name lookup on them. This ensures that we
produce the correct signature for these functions, which has two
practical impacts:
1) When we're supporting the "implicit function declaration" feature
of C99, these functions will be implicitly declared with the right
signature rather than as a function returning "int" with no
prototype. See PR3541 for the reason why this is important (hint:
GCC always predeclares these functions).
2) If users attempt to redeclare one of these library functions with
an incompatible signature, we produce a hard error.
This patch does a little bit of work to give reasonable error
messages. For example, when we hit case #1 we complain that we're
implicitly declaring this function with a specific signature, and then
we give a note that asks the user to include the appropriate header
(e.g., "please include <stdlib.h> or explicitly declare 'malloc'"). In
case #2, we show the type of the implicit builtin that was incorrectly
declared, so the user can see the problem. We could do better here:
for example, when displaying this latter error message we say
something like:
'strcpy' was implicitly declared here with type 'char *(char *, char
const *)'
but we should really print out a fake code line showing the
declaration, like this:
'strcpy' was implicitly declared here as:
char *strcpy(char *, char const *)
This would also be good for printing built-in candidates with C++
operator overloading.
The set of C library functions supported by this patch includes all
functions from the C99 specification's <stdlib.h> and <string.h> that
(a) are predefined by GCC and (b) have signatures that could cause
codegen issues if they are treated as functions with no prototype
returning and int. Future work could extend this set of functions to
other C library functions that we know about.
llvm-svn: 64504
- Made allocation of Stmt objects using vanilla new/delete a *compiler
error* by making this new/delete "protected" within class Stmt.
- Now the only way to allocate Stmt objects is by using the new
operator that takes ASTContext& as an argument. This ensures that
all Stmt nodes are allocated from the same (pool) allocator.
- Naturally, these two changes required that *all* creation sites for
AST nodes use new (ASTContext&). This is a large patch, but the
majority of the changes are just this mechanical adjustment.
- The above changes also mean that AST nodes can no longer be
deallocated using 'delete'. Instead, one most do
StmtObject->Destroy(ASTContext&) or do
ASTContextObject.Deallocate(StmtObject) (the latter not running the
'Destroy' method).
Along the way I also...
- Made CompoundStmt allocate its array of Stmt* using the allocator in
ASTContext (previously it used std::vector). There are a whole
bunch of other Stmt classes that need to be similarly changed to
ensure that all memory allocated for ASTs comes from the allocator
in ASTContext.
- Added a new smart pointer ExprOwningPtr to Sema.h. This replaces
the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used
'delete' to free memory instead of a Stmt's 'Destroy' method.
Big thanks to Doug Gregor for helping with the acrobatics of making
'new/delete' private and the new smart pointer ExprOwningPtr!
llvm-svn: 63997
ASTContext. This required changing all clients to pass in the ASTContext& to the
constructor of StringLiteral. I also changed all allocations of StringLiteral to
use new(ASTContext&).
Along the way, I updated a bunch of new()'s in StmtSerialization.cpp to use the
allocator from ASTContext& (not complete).
llvm-svn: 63958
represents an implicit value-initialization of a subobject of a
particular type. This replaces the (ab)use of CXXZeroValueInitExpr
within initializer lists for the "holes" that occur due to the use of
C99 designated initializers.
The new test case is currently XFAIL'd, because CodeGen's
ConstExprEmitter (in lib/CodeGen/CGExprConstant.cpp) needs to be
taught to value-initialize when it sees ImplicitValueInitExprs.
llvm-svn: 63317
The approach I've taken in this patch is relatively straightforward,
although the code itself is non-trivial. Essentially, as we process
an initializer list we build up a fully-explicit representation of the
initializer list, where each of the subobject initializations occurs
in order. Designators serve to "fill in" subobject initializations in
a non-linear way. The fully-explicit representation makes initializer
lists (both with and without designators) easy to grok for codegen and
later semantic analyses. We keep the syntactic form of the initializer
list linked into the AST for those clients interested in exactly what
the user wrote.
Known limitations:
- Designating a member of a union that isn't the first member may
result in bogus initialization (we warn about this)
- GNU array-range designators are not supported (we warn about this)
llvm-svn: 63242
accurately states what the function is trying to do and how it is
different from Expr::isEvaluatable. Also get rid of a parameter that is both
unused and inaccurate.
llvm-svn: 62951
designated initializers. This implementation should cover all of the
constraints in C99 6.7.8, including long, complex designations and
computing the size of incomplete array types initialized with a
designated initializer. Please see the new test-case and holler if you
find cases where this doesn't work.
There are still some wrinkles with GNU's anonymous structs and
anonymous unions (it isn't clear how these should work; we'll just
follow GCC's lead) and with designated initializers for the members of a
union. I'll tackle those very soon.
CodeGen is still nonexistent, and there's some leftover code in the
parser's representation of designators that I'll also need to clean up.
llvm-svn: 62737
information for declarations that were referenced via a qualified-id,
e.g., N::C::value. We keep track of the location of the start of the
nested-name-specifier. Note that the difference between
QualifiedDeclRefExpr and DeclRefExpr does have an effect on the
semantics of function calls in two ways:
1) The use of a qualified-id instead of an unqualified-id suppresses
argument-dependent lookup
2) If the name refers to a virtual function, the qualified-id
version will call the function determined statically while the
unqualified-id version will call the function determined dynamically
(by looking up the appropriate function in the vtable).
Neither of these features is implemented yet, but we do print out
qualified names for QualifiedDeclRefExprs as part of the AST printing.
llvm-svn: 61789
Make C++ classes track the POD property (C++ [class]p4)
Track the existence of a copy assignment operator.
Implicitly declare the copy assignment operator if none is provided.
Implement most of the parsing job for the G++ type traits extension.
Fully implement the low-hanging fruit of the type traits:
__is_pod: Whether a type is a POD.
__is_class: Whether a type is a (non-union) class.
__is_union: Whether a type is a union.
__is_enum: Whether a type is an enum.
__is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1).
llvm-svn: 61746
- Overloading has to cope with having both static and non-static
member functions in the overload set.
- The call may or may not have an implicit object argument,
depending on the syntax (x.f() vs. f()) and the context (static
vs. non-static member function).
- We now generate MemberExprs for implicit member access expression.
- We now cope with mutable whenever we're building MemberExprs.
llvm-svn: 61329
which can refer to static data members, enumerators, and member
functions as well as to non-static data members.
Implement correct lvalue computation for member references in C++.
Compute the result type of non-static data members of reference type properly.
llvm-svn: 61294
and separates lexical name lookup from qualified name lookup. In
particular:
* Make DeclContext the central data structure for storing and
looking up declarations within existing declarations, e.g., members
of structs/unions/classes, enumerators in C++0x enums, members of
C++ namespaces, and (later) members of Objective-C
interfaces/implementations. DeclContext uses a lazily-constructed
data structure optimized for fast lookup (array for small contexts,
hash table for larger contexts).
* Implement C++ qualified name lookup in terms of lookup into
DeclContext.
* Implement C++ unqualified name lookup in terms of
qualified+unqualified name lookup (since unqualified lookup is not
purely lexical in C++!)
* Limit the use of the chains of declarations stored in
IdentifierInfo to those names declared lexically.
* Eliminate CXXFieldDecl, collapsing its behavior into
FieldDecl. (FieldDecl is now a ScopedDecl).
* Make RecordDecl into a DeclContext and eliminates its
Members/NumMembers fields (since one can just iterate through the
DeclContext to get the fields).
llvm-svn: 60878
expressions, and value-dependent expressions. This permits us to parse
some template definitions.
This is not a complete solution; we're missing type- and
value-dependent computations for most of the expression types, and
we're missing checks for dependent types and type-dependent
expressions throughout Sema.
llvm-svn: 60615
parameters, with some semantic analysis:
- Template parameters are introduced into template parameter scope
- Complain about template parameter shadowing (except in Microsoft mode)
Note that we leak template parameter declarations like crazy, a
problem we'll remedy once we actually create proper declarations for
templates.
Next up: dependent types and value-dependent/type-dependent
expressions.
llvm-svn: 60597
built-in operator candidates. Test overloading of '&' and ','.
In C++, a comma expression is an lvalue if its right-hand
subexpression is an lvalue. Update Expr::isLvalue accordingly.
llvm-svn: 59643
post-decrement, including support for generating all of the built-in
operator candidates for these operators.
C++ and C have different rules for the arguments to the builtin unary
'+' and '-'. Implemented both variants in Sema::ActOnUnaryOp.
In C++, pre-increment and pre-decrement return lvalues. Update
Expr::isLvalue accordingly.
llvm-svn: 59638
function call created in response to the use of operator syntax that
resolves to an overloaded operator in C++, e.g., "str1 +
str2" that resolves to std::operator+(str1, str2)". We now build a
CXXOperatorCallExpr in C++ when we pick an overloaded operator. (But
only for binary operators, where we actually implement overloading)
I decided *not* to refactor the current CallExpr to make it abstract
(with FunctionCallExpr and CXXOperatorCallExpr as derived
classes). Doing so would allow us to make CXXOperatorCallExpr a little
bit smaller, at the cost of making the argument and callee accessors
virtual. We won't know if this is going to be a win until we can parse
lots of C++ code to determine how much memory we'll save by making
this change vs. the performance penalty due to the extra virtual
calls.
llvm-svn: 59306
some more bullet-proofing/enhancements for tryEvaluate. This shouldn't
cause any behavior changes except for handling cases where we were
crashing before and being able to evaluate a few more cases in tryEvaluate.
This should settle the minor mess surrounding r59196.
llvm-svn: 59224
little rude; I figure it's cleaner to just back this out now so
it doesn't get forgotten or mixed up with other checkins.
The modification to isICE is simply wrong; I've added a test that the
change to isICE breaks.
I'm pretty sure the modification to tryEvaluate is also wrong.
At the very least, there's some serious miscommunication going on here,
as this is going in exactly the opposite direction of r59105. My
understanding is that tryEvaluate is not supposed to care about side
effects. That said, a lot of the clients to tryEvaluate are
expecting it to enforce a no-side-effects policy, so we probably need
another method that provides that guarantee.
llvm-svn: 59212
- Evaluation of , operator used bogus assumption that LHS could be
evaluated as an integral expression even though its type is
unspecified.
This change is making isICE very permissive of the LHS in non-evaluated
contexts because it is not clear what predicate we would use to reject
code here. The standard didn't offer me any guidance; opinions?
llvm-svn: 59196
functions for built-in operators, e.g., the builtin
bool operator==(int const*, int const*)
can be used for the expression "x1 == x2" given:
struct X {
operator int const*();
} x1, x2;
The scheme for handling these built-in operators is relatively simple:
for each candidate required by the standard, create a special kind of
candidate function for the built-in. If overload resolution picks the
built-in operator, we perform the appropriate conversions on the
arguments and then let the normal built-in operator take care of it.
There may be some optimization opportunity left: if we can reduce the
number of built-in operator overloads we generate, overload resolution
for these cases will go faster. However, one must be careful when
doing this: GCC generates too few operator overloads in our little
test program, and fails to compile it because none of the overloads it
generates match.
Note that we only support operator overload for non-member binary
operators at the moment. The other operators will follow.
As part of this change, ImplicitCastExpr can now be an lvalue.
llvm-svn: 59148
of copy initialization. Other pieces of the puzzle:
- Try/Perform-ImplicitConversion now handles implicit conversions
that don't involve references.
- Try/Perform-CopyInitialization uses
CheckSingleAssignmentConstraints for C. PerformCopyInitialization
is now used for all argument passing and returning values from a
function.
- Diagnose errors with declaring references and const values without
an initializer. (Uses a new Action callback, ActOnUninitializedDecl).
We do not yet have implicit conversion sequences for reference
binding, which means that we don't have any overloading support for
reference parameters yet.
llvm-svn: 58353
- Do not allow expressions to ever have reference type
- Extend Expr::isLvalue to handle more cases where having written a
reference into the source implies that the expression is an lvalue
(e.g., function calls, C++ casts).
- Make GRExprEngine::VisitCall treat the call arguments as lvalues when
they are being bound to a reference parameter.
llvm-svn: 58306
- CastExpr is the root of all casts
- ImplicitCastExpr is (still) used for all explicit casts
- ExplicitCastExpr is now the root of all *explicit* casts
- ExplicitCCastExpr (new name needed!?) is a C-style cast in C or C++
- CXXFunctionalCastExpr inherits from ExplicitCastExpr
- CXXNamedCastExpr inherits from ExplicitCastExpr and is the root of all
of the C++ named cast expression types (static_cast, dynamic_cast, etc.)
- Added classes CXXStaticCastExpr, CXXDynamicCastExpr,
CXXReinterpretCastExpr, and CXXConstCastExpr to
Also, fixed returned-stack-addr.cpp, which broke once when we fixed
reinterpret_cast to diagnose double->int* conversions and again when
we eliminated implicit conversions to reference types. The fix is in
both testcase and SemaChecking.cpp.
Most of this patch is simply support for the renaming. There's very
little actual change in semantics.
llvm-svn: 58264
- Implement child_begin() and child_end() for AsmStmt. Previously these had stub implementations that did not iterate over the input/output operands of an inline assembly statement.
- Use ExprIterator for performing iteration over input/output operands.
llvm-svn: 58261
aren't trying to compare with address-space qualifiers (for now).
Clean up handing of DeclRefExprs in Expr::isLvalue and refactor part
of the check into a static DeclCanBeLvalue.
llvm-svn: 57980
Changes:
- Sema::IsQualificationConversion determines whether we have a qualification
conversion.
- Sema::CheckSingleAssignment constraints now follows the C++ rules in C++,
performing an implicit conversion from the right-hand side to the type of
the left-hand side rather than checking based on the C notion of
"compatibility". We now rely on the implicit-conversion code to
determine whether the conversion can happen or
not. Sema::TryCopyInitialization has an ugly reference-related
hack to cope with the initialization of references, for now.
- When building DeclRefExprs, strip away the reference type, since
there are no expressions whose type is a reference. We'll need to
do this throughout Sema.
- Expr::isLvalue now permits functions to be lvalues in C++ (but not
in C).
llvm-svn: 57935
- Modify BlockExpr to reference the BlockDecl.
This is "cleanup" necessary to improve our lookup semantics for blocks (to fix <rdar://problem/6272905> clang block rewriter: parameter to function not imported into block?).
Still some follow-up work to finish this (forthcoming).
llvm-svn: 57298
- Enabled for builtins which are always constant expressions
(__builtin_huge_val*, __builtin_inf*, __builtin_constant_p,
__builtin_classify_type, __builtin___CFStringMakeConstantString).
Added Builtin::Context::isConstantExpr.
- Currently overly simply interface which only works for builtins
whose constantexprness does not depend on their arguments.
CallExpr::isBuiltinConstantExpr now takes an ASTContext argument.
llvm-svn: 56983
Sebastian Redl