| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 85140
|
| |
|
|
| |
llvm-svn: 85136
|
| |
|
|
| |
llvm-svn: 85087
|
| |
|
|
|
|
| |
refers to a RecordType. Add assertions or conditions as appropriate. This fixes another crash in the Apache stdlib vector.
llvm-svn: 85055
|
| |
|
|
| |
llvm-svn: 84996
|
| |
|
|
|
|
|
|
|
| |
template instantiation. Preserve it through PCH. Show it off to the indexer.
I'm healthily ignoring the vector type cases because we don't have a sensible
TypeLoc implementation for them anyway.
llvm-svn: 84994
|
| |
|
|
|
|
|
| |
address of a member template when explicit template arguments are
provided.
llvm-svn: 84991
|
| |
|
|
| |
llvm-svn: 84981
|
| |
|
|
|
|
|
| |
in a certain project. Need to have a permananent fix later
(FIXME added).
llvm-svn: 84980
|
| |
|
|
|
|
|
| |
but also remove some methods that cause ambiguities, and generally
make CanQual<blah> more analogous to QualType.
llvm-svn: 84976
|
| |
|
|
| |
llvm-svn: 84973
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
in the DeclaratorInfo, if one is present.
Preserve source information through template instantiation. This is made
more complicated by the possibility that ParmVarDecls don't have DIs, which
is possibly worth fixing in the future.
Also preserve source information for function parameters in ObjC method
declarations.
llvm-svn: 84971
|
| |
|
|
|
|
| |
source info block with a single location.
llvm-svn: 84970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qualified reference to a declaration that is not a non-static data
member or non-static member function, e.g.,
namespace N { int i; }
int j = N::i;
Instead, extend DeclRefExpr to optionally store the qualifier. Most
clients won't see or care about the difference (since
QualifierDeclRefExpr inherited DeclRefExpr). However, this reduces the
number of top-level expression types that clients need to cope with,
brings the implementation of DeclRefExpr into line with MemberExpr,
and simplifies and unifies our handling of declaration references.
Extended DeclRefExpr to (optionally) store explicitly-specified
template arguments. This occurs when naming a declaration via a
template-id (which will be stored in a TemplateIdRefExpr) that,
following template argument deduction and (possibly) overload
resolution, is replaced with a DeclRefExpr that refers to a template
specialization but maintains the template arguments as written.
llvm-svn: 84962
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the DeclaratorInfo, one for semantic analysis), just build a single type whose
canonical type will reflect the semantic analysis (assuming the type is
well-formed, of course).
To make that work, make a few changes to the type system:
* allow the nominal pointee type of a reference type to be a (possibly sugared)
reference type. Also, preserve the original spelling of the reference type.
Both of these can be ignored on canonical reference types.
* Remove ObjCProtocolListType and preserve the associated source information on
the various ObjC TypeLocs. Preserve the spelling of protocol lists except in
the canonical form.
* Preserve some level of source type structure on parameter types, but
canonicalize on the canonical function type. This is still a WIP.
Drops code size, makes strides towards accurate source location representation,
slight (~1.7%) progression on Cocoa.h because of complexity drop.
llvm-svn: 84907
|
| |
|
|
| |
llvm-svn: 84891
|
| |
|
|
|
|
| |
This ensures that arrays of float3 are correctly padded.
llvm-svn: 84833
|
| |
|
|
|
|
| |
the copy/dispose helpers as appropriate.
llvm-svn: 84817
|
| |
|
|
| |
llvm-svn: 84787
|
| |
|
|
| |
llvm-svn: 84768
|
| |
|
|
|
|
|
| |
generate the debug information for the first parameter to the block
invoke functions. WIP.
llvm-svn: 84737
|
| |
|
|
|
|
|
| |
the API for creating DeclaratorInfos to allow callers to provide an exact
size.
llvm-svn: 84715
|
| |
|
|
|
|
|
| |
WIP. I have yet to find the magic incantation to get the structure
type to be defined. If someone has a pointer, love to hear it.
llvm-svn: 84590
|
| |
|
|
| |
llvm-svn: 84453
|
| |
|
|
|
|
| |
are updated.
llvm-svn: 84447
|
| |
|
|
|
|
|
|
|
| |
- strcmp -> ==
- OS.write(II->getName() ...) -> OS << II->getNameStr()
- Avoid std::string concatenation
- Use getNameStr().str() when an std::string is really needed.
llvm-svn: 84437
|
| |
|
|
| |
llvm-svn: 84436
|
| |
|
|
| |
llvm-svn: 84427
|
| |
|
|
| |
llvm-svn: 84423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TemplateTypeParmType with the substituted type directly; instead, replace it
with a SubstTemplateTypeParmType which will note that the type was originally
written as a template type parameter. This makes it reasonable to preserve
source information even through template substitution.
Also define the new SubstTemplateTypeParmType class, obviously.
For consistency with current behavior, we stringize these types as if they
were the underlying type. I'm not sure this is the right thing to do.
At any rate, I paled at adding yet another clause to the don't-desugar 'if'
statement, so I extracted a function to do it. The new function also does
The Right Thing more often, I think: e.g. if we have a chain of typedefs
leading to a vector type, we will now desugar all but the last one.
llvm-svn: 84412
|
| |
|
|
|
|
| |
- Really this should be simplified by the FIXME above, but I'm too deep in DFS.
llvm-svn: 84392
|
| |
|
|
| |
llvm-svn: 84389
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
TypeLoc class names to be $(Type classname)Loc. Rewrite the visitor.
Provide skeleton implementations for all the new TypeLocs.
Handle all cases in PCH. Handle a few more cases when inserting
location information in SemaType.
It should be extremely straightforward to add new location information
to existing TypeLoc objects now.
llvm-svn: 84386
|
| |
|
|
| |
llvm-svn: 84380
|
| |
|
|
|
|
| |
fixing PR4838.
llvm-svn: 84353
|
| |
|
|
|
|
|
|
| |
so that we catch any macros used within the declarations and types.
Also, properly store a NULL selector.
llvm-svn: 84334
|
| |
|
|
|
|
|
| |
interface that can load those source-location entries on demand (from
another PCH file).
llvm-svn: 84287
|
| |
|
|
|
|
| |
will be the keystone of converting existing rewrites to be rewrites on TypeLocs.
llvm-svn: 84286
|
| |
|
|
| |
llvm-svn: 84245
|
| |
|
|
| |
llvm-svn: 84241
|
| |
|
|
|
|
|
|
|
|
| |
TypeLoc records for declarations; it should not be necessary to represent it
directly in the type system.
Please complain if you were using these classes and feel you can't replicate
previous functionality using the TypeLoc API.
llvm-svn: 84222
|
| |
|
|
|
|
|
|
|
| |
instantiation redeclaration semantics for function template
specializations and member functions of class template
specializations. Also, record the point of instantiation for
explicit-instantiated functions and static data members.
llvm-svn: 84188
|
| |
|
|
|
|
|
|
|
|
|
| |
most of the unsafe boilerplate out of TypeLoc. Create a QualifiedLoc class
to represent the idea that we *might* start representing source locations
of qualifiers. Dealing with qualifiers explicitly like this also lets us
efficiently ignore them in all the concrete cases.
This should make it obvious and easy to add new TypeLoc subclasses.
llvm-svn: 84168
|
| |
|
|
|
|
|
|
| |
class templates the proper linkage.
Daniel, please look over the CodeGenModule bits.
llvm-svn: 84140
|
| |
|
|
| |
llvm-svn: 84129
|
| |
|
|
|
|
| |
are never copy constructors or copy assignment operators.
llvm-svn: 84057
|
| |
|
|
| |
llvm-svn: 84039
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template as a specialization. For example, this occurs with:
template<typename T>
struct X {
template<typename U> struct Inner { /* ... */ };
};
template<> template<typename T>
struct X<int>::Inner {
T member;
};
We need to treat templates that are member specializations as special
in two contexts:
- When looking for a definition of a member template, we look
through the instantiation chain until we hit the primary template
*or a member specialization*. This allows us to distinguish
between the primary "Inner" definition and the X<int>::Inner
definition, above.
- When computing all of the levels of template arguments needed to
instantiate a member template, don't add template arguments
from contexts outside of the instantiation of a member
specialization, since the user has already manually substituted
those arguments.
Fix up the existing test for p18, which was actually wrong (but we
didn't diagnose it because of our poor handling of member
specializations of templates), and add a new test for member
specializations of templates.
llvm-svn: 83974
|
| |
|
|
|
|
|
|
|
|
| |
which is a common idiom to improve PIC'ness of code using the addr of
label extension. This implementation is a gross hack, but the only other
alternative would be to teach evalutate about this horrid combination.
While GCC allows things like "&&foo - &&bar + 1", people don't use this
in practice. This implements PR5131.
llvm-svn: 83957
|
| |
|
|
|
|
| |
about the reason, rdar://7186119.
llvm-svn: 83940
|