nested-name-specifiers. Also includes fixes to the generation of
nested-name-specifier result in the non-cached case; we were producing
lame results for namespaces and namespace aliases, which (1) didn't
always have nested-name-specifiers when we want them, and (2) did not
have the necessary "::" as part of the completion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111203 91177308-0d34-0410-b5e6-96231b3b80d8
type class, so that we can adjust priorities appropriately when the
preferred type for the context and the actual type of the completion
are similar.
This gets us one step closer to parity of the cached completion
results with the non-cached completion results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111139 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
Unused warnings for functions:
-static functions
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace
Unused warnings for variables:
-static variables
-variables in anonymous namespace
-static data members in anonymous namespace
-static data members specializations in anonymous namespace
Reveals lots of opportunities for dead code removal in llvm codebase that will
interest my esteemed colleagues.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111086 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
-static variables
-variables in anonymous namespace (fixes rdar://7794535)
-static data members in anonymous namespace
-static data members specializations in anonymous namespace
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111027 91177308-0d34-0410-b5e6-96231b3b80d8
(nonfragile-abi2), do not consider 'ivar' access
in class methods. Also, improve on diagnostics.
Radar 8304561.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111023 91177308-0d34-0410-b5e6-96231b3b80d8
qua templates. The current fix suppresses the access check entirely
in this case; to do better, we'd need to be able to say that a
particular lookup result came from a particular injected class name,
which is not easy to do with the current representation of LookupResult.
This is on my known-problems list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111009 91177308-0d34-0410-b5e6-96231b3b80d8
used when parsing (or re-parsing) a file. Also, when loading a
precompiled header into ASTUnit, create a Sema object that holds onto
semantic-analysis information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111003 91177308-0d34-0410-b5e6-96231b3b80d8
can create (and hold on to) the Sema object. Also, move Sema-related
initialization/finalization with its various consumers and external
sources into the Sema constructor and destructor, rather than placing
it in ParseAST.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110973 91177308-0d34-0410-b5e6-96231b3b80d8
from GCC's in that we warn on *any* increase in alignment requirements, not
just those that are enforced by hardware. Please let us know if this causes
major problems for you (which it shouldn't, since it's an optional warning).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110959 91177308-0d34-0410-b5e6-96231b3b80d8
can create (and hold on to) the Sema object. Also, move Sema-related
initialization/finalization with its various consumers and external
sources into the Sema constructor and destructor, rather than placing
it in ParseAST.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110952 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
that actually refer to the same underlying type, it is not an
ambiguity; add uniquing support based on the canonical type of type
declarations. Fixes <rdar://problem/8296180>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110806 91177308-0d34-0410-b5e6-96231b3b80d8
and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
breakage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110803 91177308-0d34-0410-b5e6-96231b3b80d8
implicit conversion sequences. In particular, model the "standard
conversion" from a class to its own type (or a base type) directly as
a standard conversion in the normal path *without* trying to determine
if there is a valid copy constructor. This appears to match the intent
of C++ [over.best.ics]p6 and more closely matches GCC and EDG.
As part of this, model non-lvalue reference initialization via
user-defined conversion in overloading the same way we handle it in
InitializationSequence, separating the "general user-defined
conversion" and "conversion to compatible class type" cases.
The churn in the overload-call-copycon.cpp test case is because the
test case was originally wrong; it assumed that we should do more
checking for copy constructors that we actually should, which affected
overload resolution.
Fixes PR7055. Bootstrapped okay.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110773 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Fariborz Jahanian
Argyrios Kyrtzidis
Charles Davis
Eli Friedman
Abramo Bagnara
John McCall
Sebastian Redl
Jordy Rose
Benjamin Kramer