| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration in the AST.
The new ASTContext::getCommentForDecl function searches for a comment
that is attached to the given declaration, and returns that comment,
which may be composed of several comment blocks.
Comments are always available in an AST. However, to avoid harming
performance, we don't actually parse the comments. Rather, we keep the
source ranges of all of the comments within a large, sorted vector,
then lazily extract comments via a binary search in that vector only
when needed (which never occurs in a "normal" compile).
Comments are written to a precompiled header/AST file as a blob of
source ranges. That blob is only lazily loaded when one requests a
comment for a declaration (this never occurs in a "normal" compile).
The indexer testbed now supports comment extraction. When the
-point-at location points to a declaration with a Doxygen-style
comment, the indexer testbed prints the associated comment
block(s). See test/Index/comments.c for an example.
Some notes:
- We don't actually attempt to parse the comment blocks themselves,
beyond identifying them as Doxygen comment blocks to associate them
with a declaration.
- We won't find comment blocks that aren't adjacent to the
declaration, because we start our search based on the location of
the declaration.
- We don't go through the necessary hops to find, for example,
whether some redeclaration of a declaration has comments when our
current declaration does not. Similarly, we don't attempt to
associate a \param Foo marker in a function body comment with the
parameter named Foo (although that is certainly possible).
- Verification of my "no performance impact" claims is still "to be
done".
llvm-svn: 74704
|
| |
|
|
|
|
|
| |
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
llvm-svn: 74506
|
| |
|
|
|
|
|
|
|
| |
The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.
This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.
llvm-svn: 74501
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is simple enough, but then I thought it would be nice to make PrintingPolicy
get a LangOptions so that various things can key off "bool" and "C++" independently.
This spiraled out of control. There are many fixme's, but I think things are slightly
better than they were before.
One thing that can be improved: CFG should probably have an ASTContext pointer in it,
which would simplify its clients.
llvm-svn: 74493
|
| |
|
|
|
|
|
| |
redundant, implicit instantiations of function templates and provide a
place where we can hang function template specializations.
llvm-svn: 74454
|
| |
|
|
|
|
| |
Convert clients to use ASTContext::getObjCObjectPointerType().
llvm-svn: 74424
|
| |
|
|
| |
llvm-svn: 74307
|
| |
|
|
|
|
| |
dependent. Fixes PR4444.
llvm-svn: 74175
|
| |
|
|
| |
llvm-svn: 74118
|
| |
|
|
| |
llvm-svn: 74099
|
| |
|
|
| |
llvm-svn: 73702
|
| |
|
|
|
|
|
|
|
|
|
|
| |
representation.
Add a type (ObjCObjectPointerType) and remove a type (ObjCQualifiedIdType).
This large/tedious patch is just a first step. Next step is to remove ObjCQualifiedInterfaceType. After that, I will remove the magic TypedefType for 'id' (installed by Sema). This work will enable various simplifications throughout clang (when dealing with ObjC types).
No functionality change.
llvm-svn: 73649
|
| |
|
|
|
|
| |
thereof. Patch by Anders Johnsen!
llvm-svn: 73641
|
| |
|
|
| |
llvm-svn: 73452
|
| |
|
|
|
|
|
|
| |
preprocessor and initialize it early in clang-cc. This
ensures that __has_builtin works in all modes, not just
when ASTContext is around.
llvm-svn: 73319
|
| |
|
|
| |
llvm-svn: 73316
|
| |
|
|
| |
llvm-svn: 73043
|
| |
|
|
|
|
|
|
|
|
| |
hack which introduces some strange inconsistencies in compatibility
for block pointers.
Note that unlike an earlier revision proposed on cfe-commits, this patch
still allows declaring block pointers without a prototype.
llvm-svn: 73041
|
| |
|
|
| |
llvm-svn: 72928
|
| |
|
|
| |
llvm-svn: 72827
|
| |
|
|
|
|
|
| |
position to make it consistant and to match gcc's behavior,
by placing it at the inner-most pointer.
llvm-svn: 72784
|
| |
|
|
| |
llvm-svn: 72737
|
| |
|
|
|
|
| |
Fixes an error recovery issue which caused a crash.
llvm-svn: 72733
|
| |
|
|
| |
llvm-svn: 72723
|
| |
|
|
|
|
|
| |
very much, but I have a feeling we're never going to have an
implementation that makes sense because of compatibility issues.
llvm-svn: 72715
|
| |
|
|
|
|
|
|
|
|
| |
in merge_types. It is incomplete. We probably want to issue
a warning if user attempts to change the attribute from __weak to
__strong or vice-vera. It also assumes that a __weak/__strong
attribute can not be specified with other (currently one) type
attriute.
llvm-svn: 72711
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
properties at the moment:
1. It allows stuff like "__strong id x; __weak id x;".
2. For constructs like "__strong id x; id x;", subsequent references to
x lose the objc_gc attribute.
3. This incorrectly allows merges involving the address_space attribute.
4. Constructs like "id x; /* some code using x */ __weak id x;" don't
apply the objc_gc attribute consistently to all uses of x.
The first three can probably be fixed relatively easily; the fourth
would be extremely difficult to fix.
llvm-svn: 72683
|
| |
|
|
|
|
|
|
|
| |
printing logic to help customize the output. For now, we use this
rather than a special flag to suppress the "struct" when printing
"struct X" and to print the Boolean type as "bool" in C++ but "_Bool"
in C.
llvm-svn: 72590
|
| |
|
|
|
|
| |
VLAs.
llvm-svn: 72587
|
| |
|
|
|
|
| |
keep the spec out of the canonical type this time. Net effect is currently nothing, because the spec isn't checked anywhere.
llvm-svn: 72498
|
| |
|
|
|
|
| |
might not be the right way to do it.
llvm-svn: 72490
|
| |
|
|
|
|
|
|
| |
This allows me to remove some API that I don't want to carry over to ObjCObjectPointerType.
No functionality change.
llvm-svn: 72475
|
| |
|
|
| |
llvm-svn: 72415
|
| |
|
|
|
|
| |
correctly.
llvm-svn: 72401
|
| |
|
|
| |
llvm-svn: 72210
|
| |
|
|
|
|
| |
a test case
llvm-svn: 71972
|
| |
|
|
| |
llvm-svn: 71634
|
| |
|
|
|
|
| |
only and used in class imllementations (objc2 Nonfragile ABI specific).
llvm-svn: 71571
|
| |
|
|
| |
llvm-svn: 71409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template. The injected-class-name is either a type or a template,
depending on whether a '<' follows it. As a type, the
injected-class-name's template argument list contains its template
parameters in declaration order.
As part of this, add logic for canonicalizing declarations, and be
sure to canonicalize declarations used in template names and template
arguments.
A TagType is dependent if the declaration it references is dependent.
I'm not happy about the rather complicated protocol needed to use
ASTContext::getTemplateSpecializationType.
llvm-svn: 71408
|
| |
|
|
| |
llvm-svn: 71405
|
| |
|
|
| |
llvm-svn: 71184
|
| |
|
|
|
|
| |
improves type identity with dependent types.
llvm-svn: 71152
|
| |
|
|
|
|
| |
until we've had a lot more discussion.
llvm-svn: 71125
|
| |
|
|
|
|
|
|
|
|
|
|
| |
compensating for super classes). This was making the reported class
sizes for empty classes very, very wrong.
- Also, we now report the size info for an empty class like gcc (as
the offset of the start, not as 0, 0).
- Add a few more test cases we were mishandling before (padding bit
field at end of struct, for example).
llvm-svn: 70938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- This implements gcc style Objective-C interface layout (I
think). Currently it is always off, there is no functionality
change unless this is passed.
For the curious, the deal is that gcc lays out the fields of a
subclass as if they were part of the superclass. That is, the
subclass fields immediately follow the super class fields instead
of being padded to the alignment of the superclass structure.
- Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
llvm-gcc uses it in 32-bit only, for reasons which aren't clear
yet. We probably want to switch to matching gcc, once this makes it
through testing... my hope is that we can also fix llvm-gcc in
order to maintain compatibility between the compilers.
llvm-svn: 70827
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
via CollectObjCIvars.
- In places where we need them, we should have the implementation and
access the properties through it.
This is a fairly substantial functionality change:
1. @encode no longer encodes synthesized ivars, ever.
2. The ivar layout bitmap no longer encodes information for
synthesized ivars in superclasses. Well, actually I had already
broken that, but it is intentional now.
We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.
Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.
I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.
llvm-svn: 70822
|
| |
|
|
| |
llvm-svn: 70780
|
| |
|
|
|
|
|
|
|
|
|
| |
struct.
- We still need to do more lookup than necessary because ivars don't
live in a reasonable DeclContext.
- The only remaining client of the interface shadow struct is the
ivar layout bitmap.
llvm-svn: 70756
|
| |
|
|
|
|
|
| |
invalidated by layout out the super class, we cannot cache the map
entry.
llvm-svn: 70693
|