pretty sure we want to keep constant expression verification outside of
Evaluate. Because of that, the short-circuit evaluation doesn't
generally make sense, and the comma warning doesn't make sense in its
current form.
llvm-svn: 65525
I know, these follow the exact same rules as pointers, so I just made
them use the same codepath. Someone more familiar with ObjC should
double-check this, though.
llvm-svn: 65261
- PR3463, PR3398, <rdar://problem/6553401> crash on relocatable
symbol addresses as constants in static locals.
- There are many more scenarious we could handle (like arithmetic on
such an int) but this is the main use case.
llvm-svn: 65074
manual setting of the Result.
- Idiom now enforces that result will always have correct width and
type; this exposed three new bugs:
o Enum constant decl value can have different width than type
(PR3173).
o EvaluateInteger should not run an IntExprEvaluator over
non-integral expressions.
o FloatExprEvaluate was not handling casts correctly (it was
evaluating the cast in the IntExprEvaluator!).
llvm-svn: 65053
- Handles assignment to Result with appropriate type.
- Simplifies & encapsulates most direct handling of the Result value;
prep for allowing IntExprEvaluator to deal with LValue APValues.
- No intended functionality change.
llvm-svn: 65038
- Renamed to getDeclAlignInBytes since most other query functions
work in bits.
- Fun to track down as isIntegerConstantExpr was getting it right,
but Evaluate() was getting it wrong. Maybe we should assert they
compute the same thing when they succeed?
llvm-svn: 64828
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
- Lift (int,float) -> (int,float) conversion into separate routines.
- Fix handling of, e.g., char -> _Complex int, which was producing a
_Complex char value instead.
llvm-svn: 63278
evaluation (alternate part of real/imag init was being set to 3 not 0
because the wrong APFloat constructor was being called).
- Test cases coming once some more support is in.
llvm-svn: 63264
.def file for each library. This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.
Patch by Anders Johnsen!
llvm-svn: 63111
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
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
code were working correctly, it would be a no-op, but it's not really a
proper fix. That said, I don't really want to touch the enum code at
the moment because I don't understand it very well, and this seems to
be a relatively visible regression.
llvm-svn: 60680
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
This pushes it a lot closer to being able to deal with most of the stuff
CodeGen's constant expression evaluator knows how to deal with. This
also fixes PR3003.
The test could possibly use some improvement, but this'll work for now.
Test 6 is inspired by PR3003; the other tests are mostly just designed
to exercise the new code. The reason for the funny structure of the
tests is that type fixing for arrays inside of structs is the only place
in Sema that calls tryEvaluate, at least for the moment.
llvm-svn: 59125
crashing because we errors are ignored in subexpressions that are not evaluated,
but we still evaluate the result of parents. This would cause an assertion
because the erroneous subexpr didn't have its result value set to the right type.
llvm-svn: 59110
- Kill unnecessary #includes in .cpp files. This is an automatic
sweep so some things removed are actually used, but happen to be
included by a previous header. I tried to get rid of the obvious
examples and this was the easiest way to trim the #includes in one
fell swoop.
- We now return to regularly scheduled development.
llvm-svn: 54632
Eli Friedman