| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
llvm-svn: 98149
|
|
|
|
|
|
| |
of the class name.
llvm-svn: 97943
|
|
|
|
|
|
| |
Fixes PR6373.
llvm-svn: 97037
|
|
|
|
|
|
|
|
| |
This was causing buildbot breakage.
This reverts commit d46e952cc8cb8d9eed8657d9a0b267910a0f745a.
llvm-svn: 96652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to initializer expressions in an array allocated using ASTContext.
This plugs a memory leak when ASTContext uses a BumpPtrAllocator to
allocate memory for AST nodes.
In my mind this isn't an ideal solution; it would be nice to have
a general "vector"-like class that allocates memory using ASTContext,
but whose guts could be separated from the methods of InitListExpr
itself. I haven't gone and taken this approach yet because it isn't
clear yet if we'll eventually want an alternate solution for recylcing
memory using by InitListExprs as we are constructing the ASTs.
llvm-svn: 96642
|
|
|
|
|
|
|
|
| |
which describes temporary objects of class type in C++. Use this to
provide a more-specific, remappable diagnostic when takin the address
of such a temporary.
llvm-svn: 96396
|
|
|
|
|
|
| |
unused-value warnings. This is a common macro idiom.
llvm-svn: 96326
|
|
|
|
|
|
| |
in objective-c++ mode (do it for objective-c only).
llvm-svn: 96012
|
|
|
|
|
|
| |
associated with ASTContext. This fixes yet another leak (<rdar://problem/7639260>).
llvm-svn: 95930
|
|
|
|
|
|
| |
complete function type of the member functions (using PredefinedExpr::ComputeName.
llvm-svn: 95887
|
|
|
|
|
|
| |
using property dot-syntax. Fixes radar 7628953.
llvm-svn: 95838
|
|
|
|
|
|
|
|
| |
with
out-of-line initializers as integer constant expressions. Fixes PR6206.
llvm-svn: 95463
|
|
|
|
|
|
| |
working code, for no apparent reason.
llvm-svn: 95244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon. This also simplifies the code generated by the GNU runtime a bit.
- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.
- Recognise @selector() expressions as valid static initialisers (as GCC does).
- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants. These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.
- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector. This is needed for generating typed selectors from @selector() expressions (as GCC does). Ideally, this information should be stored in the Selector, but that would be an invasive change. We should eventually add checks for common uses of @selector() expressions. Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:
- (id)performSelector: __attribute__((selector_types(id, SEL, id)))(SEL)
withObject: (id)object;
Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature. We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.
- Made @selector() expressions emit type info if available and the runtime supports it.
Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac. This currently just assert()s.
llvm-svn: 95189
|
|
|
|
|
|
| |
appropriately. Call out a few missing cases in the expression mangler.
llvm-svn: 95176
|
|
|
|
|
|
| |
definition. With that in mind, rename getDefinition to getAnyInitializer (to distinguish it from getInit) and reimplement it in terms of isThisDeclarationADefinition. Update all code to use this new function.
llvm-svn: 94999
|
|
|
|
| |
llvm-svn: 94963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
requires a temporary. Previously, we were building an initialization
sequence that bound to the bit-field as if it were a real lvalue. Note
that we previously (and still) diagnose binding of non-const
references to bit-fields, as we should.
There's no real way to test that this code is correct, since reference
binding does not *currently* have any representation in the AST. This
fix should make it easier for that to happen, so I've verified this
fix with...
Added InitializationSequence::dump(), to print an initialization
sequence for debugging purposes.
llvm-svn: 94826
|
|
|
|
| |
llvm-svn: 94791
|
|
|
|
|
|
|
|
| |
references a const variable of integral type, the initializer may be
in a different declaration than the one that name-lookup saw. Find the
initializer anyway. Fixes PR6045.
llvm-svn: 93514
|
|
|
|
|
|
| |
ASTContext. Fixes <rdar://problem/7495428>.
llvm-svn: 92867
|
|
|
|
|
|
|
|
| |
caught several cases where we were not doing the right thing. I'm
not completely sure all cases are being handled correctly, but this should
be an improvement.
llvm-svn: 92281
|
|
|
|
|
|
| |
functions in __PRETTY_FUNCTION__ predefined expressions.
llvm-svn: 92171
|
|
|
|
| |
llvm-svn: 92095
|
|
|
|
| |
llvm-svn: 91807
|
|
|
|
| |
llvm-svn: 91803
|
|
|
|
|
|
| |
is an lvalue. Fixes PR5787.
llvm-svn: 91765
|
|
|
|
|
|
| |
using objective-c property. (fixes radar 7449707)
llvm-svn: 91474
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- During instantiation, drop default arguments from constructor and
call expressions; they'll be recomputed anyway, and we don't want
to instantiate them twice.
- Rewrote the instantiation of variable initializers to cope with
non-dependent forms properly.
Together, these fix a handful of problems I introduced with the switch
to always rebuild expressions from the source code "as written."
llvm-svn: 91315
|
|
|
|
|
|
| |
no extra safety anyway.
llvm-svn: 91207
|
|
|
|
|
|
| |
(fixes radar 7465023).
llvm-svn: 91171
|
|
|
|
|
|
| |
(fixes radar 7457534).
llvm-svn: 90995
|
|
|
|
| |
llvm-svn: 90902
|
|
|
|
|
|
| |
Template instantiation can re-use DeclRefExprs.
llvm-svn: 90848
|
|
|
|
|
|
| |
generating a predefined expr for them.
llvm-svn: 90725
|
|
|
|
| |
llvm-svn: 90549
|
|
|
|
|
|
| |
don't infinitely recurse for cases we can't evaluate.
llvm-svn: 90480
|
|
|
|
| |
llvm-svn: 90313
|
|
|
|
|
|
|
|
| |
Create a new UnresolvedMemberExpr for these lookups. Assorted hackery
around qualified member expressions; this will all go away when we
implement the correct (i.e. extremely delayed) implicit-member semantics.
llvm-svn: 90161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All statements that involve conditions can now hold on to a separate
condition declaration (a VarDecl), and will use a DeclRefExpr
referring to that VarDecl for the condition expression. ForStmts now
have such a VarDecl (I'd missed those in previous commits).
Also, since this change reworks the Action interface for
if/while/switch/for, use FullExprArg for the full expressions in those
expressions, to ensure that we're emitting
Note that we are (still) not generating the right cleanups for
condition variables in for statements. That will be a follow-on
commit.
llvm-svn: 89817
|
|
|
|
|
|
|
|
|
|
|
|
| |
DependentScopeDeclRefExpr support storing templateids. Unite the common
code paths between ActOnDeclarationNameExpr and ActOnTemplateIdExpr.
This gets us to a point where we don't need to store function templates in
the AST using TemplateNames, which is critical to ripping out OverloadedFunction.
Also resolves a few FIXMEs.
llvm-svn: 89785
|
|
|
|
| |
llvm-svn: 89692
|
|
|
|
|
|
| |
DeclRefExprs
llvm-svn: 89649
|
|
|
|
|
|
|
|
|
|
| |
locations" into
a new class. Use it pervasively throughout Sema.
My fingers hurt.
llvm-svn: 89638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into pretty much everything about overload resolution in order to wean
BuildDeclarationNameExpr off LookupResult::getAsSingleDecl(). Replace
UnresolvedFunctionNameExpr with UnresolvedLookupExpr, which generalizes the
idea of a non-member lookup that we haven't totally resolved yet, whether by
overloading, argument-dependent lookup, or (eventually) the presence of
a function template in the lookup results.
Incidentally fixes a problem with argument-dependent lookup where we were
still performing ADL even when the lookup results contained something from
a block scope.
Incidentally improves a diagnostic when using an ObjC ivar from a class method.
This just fell out from rewriting BuildDeclarationNameExpr's interaction with
lookup, and I'm too apathetic to break it out.
The only remaining uses of OverloadedFunctionDecl that I know of are in
TemplateName and MemberExpr.
llvm-svn: 89544
|
|
|
|
|
|
|
| |
rather than punting to a DependentSizedArrayType, tightening up our
type checking for template definitions. Thanks, John!
llvm-svn: 89407
|
|
|
|
|
|
|
|
| |
appropriate lookup and simply can't resolve the referrent yet, and
"dependent scope" expressions, where we can't do the lookup yet because the
entity we need to look into is a dependent type.
llvm-svn: 89402
|
|
|
|
| |
llvm-svn: 89106
|
|
|
|
| |
llvm-svn: 86994
|
|
|
|
|
|
|
| |
type to look at the volatile specifier. I found these all from just
hand auditing the code.
llvm-svn: 85967
|