I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113821 91177308-0d34-0410-b5e6-96231b3b80d8
to an "overloaded" set of declarations. This cursor kind works for
unresolved references to functions/templates (e.g., a call within a
template), using declarations, and Objective-C class and protocol
forward declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113805 91177308-0d34-0410-b5e6-96231b3b80d8
currently expect that to be useful for plugins, and this is important for
startup performance:
--
ddunbar@lordcrumb:tmp$ touch empty.c
ddunbar@lordcrumb:tmp$ runN 100 ~/llvm.obj.64/Release/bin/clang -c empty.c
name avg min med max SD total
user 0.0054 0.0052 0.0054 0.0055 0.0000 0.5350
sys 0.0084 0.0090 0.0078 0.0087 0.0008 0.8390
wall 0.0149 0.0149 0.0149 0.0149 0.0003 1.4943
ddunbar@lordcrumb:tmp$ runN 100 ~/llvm.obj.64/Release/bin/clang -c empty.c
name avg min med max SD total
user 0.0036 0.0036 0.0036 0.0038 0.0000 0.3646
sys 0.0072 0.0071 0.0068 0.0070 0.0006 0.7158
wall 0.0123 0.0123 0.0122 0.0136 0.0003 1.2262
--
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113638 91177308-0d34-0410-b5e6-96231b3b80d8
constructor, in source order. Also introduces a new reference kind for
class members, which is used here (for member initializers) and will
also be used for designated initializers and offsetof.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113545 91177308-0d34-0410-b5e6-96231b3b80d8
CXXTemporaryObjectExpr, CXXScalarValueInitExpr, and
CXXUnresolvedConstructExpr, getting rid of a bunch of FIXMEs in the
process.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113319 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by nobled.
I also took the opportunity to make the field private since now it is only ready from the
outside.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113138 91177308-0d34-0410-b5e6-96231b3b80d8
last of the C++-specific expressions where we have decent source
information in the AST already. In particular, various
object-construction expressions (CXXNewExpr, CXXTemporaryObjectExpr)
still have poor source-location information that needs to be addressed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112981 91177308-0d34-0410-b5e6-96231b3b80d8
cursors. Sadly, this visitation is a hack, because we don't have
proper source-location information for nested-name-specifiers in the
AST. It does improve on the status quo, however.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112837 91177308-0d34-0410-b5e6-96231b3b80d8
clang_getSpecializedCursorTemplate(), which determines the template
(or member thereof) that the given cursor specializes or from which it
was instantiated. This routine can be used to establish a link between
templates and their instantiations/specializations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112780 91177308-0d34-0410-b5e6-96231b3b80d8
three different kinds of AST nodes to represent using declarations:
UsingDecl, UnresolvedUsingValueDecl, and
UnresolvedUsingTypenameDecl. These three are collapsed into a single
cursor kind for using declarations, since libclang clients don't need
the distinction.
Several related changes here:
- Cursor visitation of the three AST nodes for using declarations
- Proper source-range computation for these AST nodes
- Using declarations have no USRs, since they don't actually declare
any entities.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112730 91177308-0d34-0410-b5e6-96231b3b80d8
in a few related ways:
- Don't recurse into instantiations of templates.
- Recurse into explicit specializations.
- Visit the template arguments of an explicit specialization or
explicit instantiation.
- Include template specialization arguments in the USRs for class
template specializations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112720 91177308-0d34-0410-b5e6-96231b3b80d8
suppressing USRs). Also, fix up the source location information for
using directives so that the declaration location refers to the
namespace name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112693 91177308-0d34-0410-b5e6-96231b3b80d8
with a new cursor kind for a reference to a namespace.
There's still some oddities in the source location information for
NamespaceAliasDecl that I'll address with a separate commit, so the
source locations displayed in the load-namespaces.cpp test will
change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112676 91177308-0d34-0410-b5e6-96231b3b80d8
determines the kind of declaration that would be generated if the
given template were instantiated. This allows a client to distinguish
among class/struct/union templates and function/member function/static
member function templates.
Also, teach clang_CXXMethod_isStatic() about function templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112655 91177308-0d34-0410-b5e6-96231b3b80d8
template. Such cursors occur, for example, in template specialization
types such as vector<int>. Note that we do not handle the
super-interesting case where the template name is unresolved, e.g.,
within a template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112636 91177308-0d34-0410-b5e6-96231b3b80d8
libclang. This includes:
- Cursor kind for function templates, with visitation logic
- Cursor kinds for template parameters, with visitation logic
- Visitation logic for template specialization types, qualified type
locations
- USR generation for function templates, template specialization
types, template parameter types.
Also happens to fix PR7804, which I tripped across while testing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112604 91177308-0d34-0410-b5e6-96231b3b80d8
conversion functions. This introduces new cursor kinds for these three
C++ entities, and reworks visitation of function declarations so that
we get type-source information for the names.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112600 91177308-0d34-0410-b5e6-96231b3b80d8
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112458 91177308-0d34-0410-b5e6-96231b3b80d8
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
Provide a libclang function that sorts the results.
3rd try. How embarrassing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112180 91177308-0d34-0410-b5e6-96231b3b80d8
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
Provide a libclang function that sorts the results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112149 91177308-0d34-0410-b5e6-96231b3b80d8
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112095 91177308-0d34-0410-b5e6-96231b3b80d8
r110903 introduced a dependency from Frontend to every library that
declared an Action by introducing Action references that previously
resided in the driver in the file ExecuteCompilerInvocation.cpp.
This patch moves ExecuteCompilerInvocation to a new library named
FrontendTool which is intended to bear these dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111873 91177308-0d34-0410-b5e6-96231b3b80d8
of a cursor or code-completion result, e.g., whether that result
refers to an unavailable, deleted, or deprecated declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111858 91177308-0d34-0410-b5e6-96231b3b80d8
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111667 91177308-0d34-0410-b5e6-96231b3b80d8
sure to (1) actually use the remapped files we were given rather
than old data, and (2) keep the remapped files alive until the
code-completion results are destroyed. Big thanks to Daniel for the
test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111597 91177308-0d34-0410-b5e6-96231b3b80d8
Now all classes derived from Attr are generated from TableGen.
Additionally, Attr* is no longer its own linked list; SmallVectors or
Attr* are used. The accompanying LLVM commit contains the updates to
TableGen necessary for this.
Some other notes about newly-generated attribute classes:
- The constructor arguments are a SourceLocation and a Context&,
followed by the attributes arguments in the order that they were
defined in Attr.td
- Every argument in Attr.td has an appropriate accessor named getFoo,
and there are sometimes a few extra ones (such as to get the length
of a variadic argument).
Additionally, specific_attr_iterator has been introduced, which will
iterate over an AttrVec, but only over attributes of a certain type. It
can be accessed through either Decl::specific_attr_begin/end or
the global functions of the same name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111455 91177308-0d34-0410-b5e6-96231b3b80d8
declarations (in addition to macros). Each kind of declaration maps to
a certain set of completion contexts, and the ASTUnit completion logic
introduces the completion strings for those declarations if the actual
code-completion occurs in one of the contexts where it matters.
There are a few new code-completion-context kinds. Without these,
certain completions (e.g., after "using namespace") would need to
suppress all global completions, which would be unfortunate.
Note that we don't get the priorities right for global completions,
because we don't have enough type information. We'll need a way to
compare types in an ASTContext-agnostic way before this can be
implemented.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111093 91177308-0d34-0410-b5e6-96231b3b80d8
when the CXTranslationUnit_CacheCompletionResults option is given to
clang_parseTranslationUnit(). Essentially, we compute code-completion
results for macro definitions after we have parsed the file, then
store an ASTContext-agnostic version of those results (completion
string, cursor kind, priority, and active contexts) in the
ASTUnit. When performing code completion in that ASTUnit, we splice
the macro definition results into the results provided by the actual
code-completion (which has had macros turned off) before libclang gets
those results. We use completion context information to only splice in
those results that make sense for that context.
With a completion involving all of the macros from Cocoa.h and a few other
system libraries (totally ~8500 macro definitions) living in a
precompiled header, we get about a 9% performance improvement from
code completion, since we no longer have to deserialize all of the
macro definitions from the precompiled header.
Note that macro definitions are merely the canary; the cache is
designed to also support other top-level declarations, which should be
a bigger performance win. That optimization will be next.
Note also that there is no mechanism for determining when to throw
away the cache and recompute its contents.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111051 91177308-0d34-0410-b5e6-96231b3b80d8
the code-completion consumer. The consumer can use this information to
augument, filter, or display the code-completion results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110858 91177308-0d34-0410-b5e6-96231b3b80d8