| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
(C) API, and will likely grow further in this direction in the future.
llvm-svn: 102779
|
|
|
|
| |
llvm-svn: 102748
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Amadini.
This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.
OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.
There are two major caveats to this patch:
1) CodeGen cannot handle the case where __builtin_offsetof is not a
constant expression, so it produces an error. So, to avoid
regressing in C, we retain the old UnaryOperator-based
__builtin_offsetof implementation in C while using the shiny new
OffsetOfExpr implementation in C++. The old implementation can go
away once we have proper CodeGen support for this case, which we
expect won't cause much trouble in C++.
2) __builtin_offsetof doesn't work well with non-POD class types,
particularly when the designated field is found within a base
class. I will address this in a subsequent patch.
Fixes PR5880 and a bunch of assertions when building Boost.Python
tests.
llvm-svn: 102542
|
|
|
|
| |
llvm-svn: 102145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. The ObjCMessageExpr node represents four different kinds of
message sends in a single AST node:
1) Send to a object instance described by an expression (e.g., [x method:5])
2) Send to a class described by the class name (e.g., [NSString method:5])
3) Send to a superclass class (e.g, [super method:5] in class method)
4) Send to a superclass instance (e.g., [super method:5] in instance method)
Previously these four cases where tangled together. Now, they have
more distinct representations. Specific changes:
1) Unchanged; the object instance is represented by an Expr*.
2) Previously stored the ObjCInterfaceDecl* referring to the class
receiving the message. Now stores a TypeSourceInfo* so that we know
how the class was spelled. This both maintains typedef information
and opens the door for more complicated C++ types (e.g., dependent
types). There was an alternative, unused representation of these
sends by naming the class via an IdentifierInfo *. In practice, we
either had an ObjCInterfaceDecl *, from which we would get the
IdentifierInfo *, or we fell into the case below...
3) Previously represented by a class message whose IdentifierInfo *
referred to "super". Sema and CodeGen would use isStr("super") to
determine if they had a send to super. Now represented as a
"class super" send, where we have both the location of the "super"
keyword and the ObjCInterfaceDecl* of the superclass we're
targetting (statically).
4) Previously represented by an instance message whose receiver is a
an ObjCSuperExpr, which Sema and CodeGen would check for via
isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
where we have both the location of the "super" keyword and the
ObjCInterfaceDecl* of the superclass we're targetting
(statically). Note that ObjCSuperExpr only has one remaining use in
the AST, which is for "super.prop" references.
The new representation of ObjCMessageExpr is 2 pointers smaller than
the old one, since it combines more storage. It also eliminates a leak
when we loaded message-send expressions from a precompiled header. The
representation also feels much cleaner to me; comments welcome!
This patch attempts to maintain the same semantics we previously had
with Objective-C message sends. In several places, there are massive
changes that boil down to simply replacing a nested-if structure such
as:
if (message has a receiver expression) {
// instance message
if (isa<ObjCSuperExpr>(...)) {
// send to super
} else {
// send to an object
}
} else {
// class message
if (name->isStr("super")) {
// class send to super
} else {
// send to class
}
}
with a switch
switch (E->getReceiverKind()) {
case ObjCMessageExpr::SuperInstance: ...
case ObjCMessageExpr::Instance: ...
case ObjCMessageExpr::SuperClass: ...
case ObjCMessageExpr::Class:...
}
There are quite a few places (particularly in the checkers) where
send-to-super is effectively ignored. I've placed FIXMEs in most of
them, and attempted to address send-to-super in a reasonable way. This
could use some review.
llvm-svn: 101972
|
|
|
|
|
|
| |
@encode expression.
llvm-svn: 101907
|
|
|
|
| |
llvm-svn: 101193
|
|
|
|
|
|
| |
(e.g., distinguish between C and Objective-C language features). Currently this only returns results for declarations.
llvm-svn: 101070
|
|
|
|
| |
llvm-svn: 101059
|
|
|
|
| |
llvm-svn: 100989
|
|
|
|
| |
llvm-svn: 100589
|
|
|
|
|
|
| |
maybe-ownership vs. ownership.
llvm-svn: 100498
|
|
|
|
| |
llvm-svn: 100484
|
|
|
|
|
|
|
|
|
| |
ASTUnit. Previously, we would end up with use-after-free errors
because the Diagnostic object would be creating in one place (say,
CIndex) and its ownership would not be transferred into the
ASTUnit. Fixes <rdar://problem/7818608>.
llvm-svn: 100464
|
|
|
|
|
|
|
|
| |
- Rename "Diagnostics" and related to "StoredDiagnostics", to better
capture what we're actually storing.
- Move SourceManager and FileManager to the heap.
llvm-svn: 100441
|
|
|
|
|
|
|
| |
of macro definitions when passed to CIndex. Add test for code
completion of macros via CIndex.
llvm-svn: 100431
|
|
|
|
|
|
| |
if even they contain errors.
llvm-svn: 99594
|
|
|
|
|
|
|
| |
declaration, just in case invalid code makes the latter
incorrect. This may be the cause behind <rdar://problem/7777070>.
llvm-svn: 99179
|
|
|
|
| |
llvm-svn: 99021
|
|
|
|
|
|
|
|
| |
preprocessed entities by grouping preprocessed entities by file
ID. This drastically improves performance of repeated
clang_getCursor() calls local tests, although it is a bit ugly.
llvm-svn: 99015
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
record (which includes all macro instantiations and definitions). As
with all lay deserialization, this introduces a new external source
(here, an external preprocessing record source) that loads all of the
preprocessed entities prior to iterating over the entities.
The preprocessing record is an optional part of the precompiled header
that is disabled by default (enabled with
-detailed-preprocessing-record). When the preprocessor given to the
PCH writer has a preprocessing record, that record is written into the
PCH file. When the PCH reader is given a PCH file that contains a
preprocessing record, it will be lazily loaded (which, effectively,
implicitly adds -detailed-preprocessing-record). This is the first
case where we have sections of the precompiled header that are
added/removed based on a compilation flag, which is
unfortunate. However, this data consumes ~550k in the PCH file for
Cocoa.h (out of ~9.9MB), and there is a non-trivial cost to gathering
this detailed preprocessing information, so it's too expensive to turn
on by default. In the future, we should investigate a better encoding
of this information.
llvm-svn: 99002
|
|
|
|
| |
llvm-svn: 98982
|
|
|
|
| |
llvm-svn: 98981
|
|
|
|
|
|
| |
tie its creation to a CC1 flag -detailed-preprocessing-record.
llvm-svn: 98963
|
|
|
|
|
|
|
|
| |
definitions) as part of the translation unit, so that normal
visitation, token-annotation, and cursor-at retrieval all see
preprocessing elements.
llvm-svn: 98935
|
|
|
|
|
|
|
|
| |
--- Reverse-merging r98907 into '.':
D test/Index/c-index-getCursor-pp.c
U tools/CIndex/CIndex.cpp
llvm-svn: 98929
|
|
|
|
|
|
|
|
| |
definitions) as part of the translation unit, so that normal
visitation, token-annotation, and cursor-at retrieval all see
preprocessing elements.
llvm-svn: 98907
|
|
|
|
| |
llvm-svn: 98878
|
|
|
|
| |
llvm-svn: 98875
|
|
|
|
|
|
|
|
| |
preprocessing record. Use that link with clang_getCursorReferenced()
and clang_getCursorDefinition() to match instantiations of a macro to
the definition of the macro.
llvm-svn: 98842
|
|
|
|
|
|
| |
generated by clang_annotateTokens().
llvm-svn: 98837
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the macro definitions and macro instantiations that are found
during preprocessing. Preprocessing records are *not* generated by
default; rather, we provide a PPCallbacks subclass that hooks into the
existing callback mechanism to record this activity.
The only client of preprocessing records is CIndex, which keeps track
of macro definitions and instantations so that they can be exposed via
cursors. At present, only token annotation uses these facilities, and
only for macro instantiations; both will change in the near
future. However, with this change, token annotation properly annotates
macro instantiations that do not produce any tokens and instantiations
of macros that are later undef'd, improving our consistency.
Preprocessing directives that are not macro definitions are still
handled by clang_annotateTokens() via re-lexing, so that we don't have
to track every preprocessing directive in the preprocessing record.
Performance impact of preprocessing records is still TBD, although it
is limited to CIndex and therefore out of the path of the main compiler.
llvm-svn: 98836
|
|
|
|
|
|
|
| |
token sequence to detect macro instantiations (that produce at least
token). WIP.
llvm-svn: 98826
|
|
|
|
|
|
|
|
| |
directives while annotating tokens in CIndex. This functionality
should probably be factored out of this routine, but we're not there
yet.
llvm-svn: 98786
|
|
|
|
|
|
| |
needs better error recovery.
llvm-svn: 98667
|
|
|
|
|
|
| |
const char*.
llvm-svn: 98630
|
|
|
|
|
|
| |
and start simplifying the interfaces in SourceManager that can fail.
llvm-svn: 98594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceManager's getBuffer() (and similar) operations. This abstract
can be used to force callers to cope with errors in getBuffer(), such
as missing files and changed files. Fix a bunch of callers to use the
new interface.
Add some very basic checks for file consistency (file size,
modification time) into ContentCache::getBuffer(), although these
checks don't help much until we've updated the main callers (e.g.,
SourceManager::getSpelling()).
llvm-svn: 98585
|
|
|
|
| |
llvm-svn: 98452
|
|
|
|
|
|
|
|
| |
tmpnam calls.
This fixes linker warnings on linux.
llvm-svn: 98439
|
|
|
|
|
|
| |
unexposed AST elements.
llvm-svn: 97985
|
|
|
|
|
|
| |
of the class name.
llvm-svn: 97943
|
|
|
|
|
|
|
|
|
|
| |
Objective-C method declaration, e.g., for
- (Foo *)myMethod;
we now have TypeSourceInfo for the Foo*.
llvm-svn: 97942
|
|
|
|
|
|
|
| |
This obviates a null dereference that can occur when 'NumErrors'
is not zero.
llvm-svn: 97849
|
|
|
|
| |
llvm-svn: 97848
|
|
|
|
| |
llvm-svn: 97831
|
|
|
|
|
|
|
| |
underlying linkage for the entity referred to by a
CXCursor.
llvm-svn: 97646
|
|
|
|
|
|
|
|
|
|
| |
copy the source buffers provided rather than referencing them
directly, so that the caller can free those buffers immediately after
calling clang_createTranslationUnitFromSourceFile(). Otherwise, we
risk hitting those buffers later (when building source ranges, forming
diagnostics, etc.).
llvm-svn: 97296
|
|
|
|
| |
llvm-svn: 96978
|
|
|
|
|
|
|
| |
the diagnostics to a FILE*, return a CXString containing the formatted
diagnostic.
llvm-svn: 96823
|