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
are formed. In particular, a diagnostic with all its strings and ranges is now
packaged up and sent to DiagnosticClients as a DiagnosticInfo instead of as a
ton of random stuff. This has the benefit of simplifying the interface, making
it more extensible, and allowing us to do more checking for things like access
past the end of the various arrays passed in.
In addition to introducing DiagnosticInfo, this also substantially changes how
Diagnostic::Report works. Instead of being passed in all of the info required
to issue a diagnostic, Report now takes only the required info (a location and
ID) and returns a fresh DiagnosticInfo *by value*. The caller is then free to
stuff strings and ranges into the DiagnosticInfo with the << operator. When
the dtor runs on the DiagnosticInfo object (which should happen at the end of
the statement), the diagnostic is actually emitted with all of the accumulated
information. This is a somewhat tricky dance, but it means that the
accumulated DiagnosticInfo is allowed to keep pointers to other expression
temporaries without those pointers getting invalidated.
This is just the minimal change to get this stuff working, but this will allow
us to eliminate the zillions of variant "Diag" methods scattered throughout
(e.g.) sema. For example, instead of calling:
Diag(BuiltinLoc, diag::err_overload_no_match, typeNames,
SourceRange(BuiltinLoc, RParenLoc));
We will soon be able to just do:
Diag(BuiltinLoc, diag::err_overload_no_match)
<< typeNames << SourceRange(BuiltinLoc, RParenLoc));
This scales better to support arbitrary types being passed in (not just
strings) in a type-safe way. Go operator overloading?!
llvm-svn: 59502
representing the names of declarations in the C family of
languages. DeclarationName is used in NamedDecl to store the name of
the declaration (naturally), and ObjCMethodDecl is now a NamedDecl.
llvm-svn: 59441
- Resume running the always inliner pass always now that LLVM has
been improved and functions with debug info can be inlined.
- Remove unused header.
llvm-svn: 59223
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
operators. For example, one can now write "x + y" where x or y is a
class or enumeration type, and Clang will perform overload resolution
for "+" based on the overloaded operators it finds.
The other kinds of overloadable operators in C++ will follow this same
approach.
Three major issues remain:
1) We don't find member operators
2) Since we don't have user-defined conversion operators, we can't
call any of the built-in overloaded operators in C++ [over.built].
3) Once we've done the semantic checks, we drop the overloaded
operator on the floor; it doesn't get into the AST at all.
llvm-svn: 58821
were being treated as type names for non-Objective-C files.
- Other lines are just because MinimalAction didn't have access to
the LangOptions.
llvm-svn: 58498
With this commit, stuff like this is very close to working...
[foo barf:^(int){ printf("whatever\n"); }];
Here is what is currently translates to...
((id (*)(id, SEL, void (^)(int)))(void *)objc_msgSend)((id)foo, sel_registerName("barf:"), (void (*)(int))__main_block_func_0);
I just need make sure the funky cast on objc_msgSend() is converted from "void (^)(int)" to "void (*)(int)". Since the cast doesn't appear in the source code, it needs to be converted in RewriteObjC::SynthMessageExpr().
llvm-svn: 58348
- Add support for -MP (phony targets).
- Use raw_ostream for output instead of std::string concatenation.
- Break long lines in a GCC (4.2) compatible manner.
- Output dependents in #included order (to match GCC).
llvm-svn: 58265
- 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
Steve Naroff