results for other, textual completion. For call completion, we now
produce enough information to show the function call argument that we
are currently on.
llvm-svn: 82592
members found in base classes have the same ranking as members found
in derived classes. However, we will introduce an informative note for
members found in base classes, showing (as a nested-name-specifier)
the qualification to name the base class, to make it clear which
members are from bases.
llvm-svn: 82586
-code-completion-at=filename:line:column
which performs code completion at the specified location by truncating
the file at that position and enabling code completion. This approach
makes it possible to run multiple tests from a single test file, and
gives a more natural command-line interface.
llvm-svn: 82571
opening parentheses and after each comma. We gather the set of visible
overloaded functions, perform "partial" overloading based on the set
of arguments that we have thus far, and return the still-viable
results sorted by the likelihood that they will be the best candidate.
Most of the changes in this patch are a refactoring of the overloading
routines for a function call, since we needed to separate out the
notion of building an overload set (common to code-completion and
normal semantic analysis) and then what to do with that overload
set. As part of this change, I've pushed explicit template arguments
into a few more subroutines.
There is still much more work to do in this area. Function templates
won't be handled well (unless we happen to deduce all of the template
arguments before we hit the completion point), nor will overloaded
function-call operators or calls to member functions.
llvm-svn: 82549
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
enumerators when either the user intentionally wrote a qualified name
(in which case we just use that nested-name-specifier to match
the user's code) or when this is the first "case" statement and we
need a qualified name to refer to an enumerator in a different scope.
llvm-svn: 82474
- after "using", show anything that can be a nested-name-specifier.
- after "using namespace", show any visible namespaces or namespace aliases
- after "namespace", show any namespace definitions in the current scope
- after "namespace identifier = ", show any visible namespaces or
namespace aliases
llvm-svn: 82251
look into the current scope for anything that could start a
nested-names-specifier. These results are ranked worse than any of the
results actually found in the lexical scope.
Perform a little more pruning of the result set, eliminating
constructors, __va_list_tag, and any duplication of declarations in
the result set. For the latter, implemented
NamespaceDecl::getCanonicalDecl.
llvm-svn: 82231
will provide the names of various enumerations currently
visible. Introduced filtering of code-completion results when we build
the result set, so that we can identify just the kinds of declarations
we want.
This implementation is incomplete for C++, since we don't consider
that the token after the tag keyword could start a
nested-name-specifier.
llvm-svn: 82222
when running the analyzer on real projects. We'll keep the change to
AnalysisManager.cpp in r82198 so that -fobjc-gc analyzes code
correctly in both GC and non-GC modes, although this may emit two
diagnostics for each bug in some cases (a better solution will come
later).
llvm-svn: 82201
pruning of diagnostics that may be emitted multiple times. This is
accomplished by adding FoldingSet profiling support to PathDiagnostic,
and then having BugReporter record what diagnostics have been issued.
This was motived to a serious bug introduced by moving the
'divide-by-zero' checking outside of GRExprEngine into a separate
'Checker' class. When analyzing code using the '-fobjc-gc' option, a
given function would be analyzed twice, but the second time various
"internal checks" would be disabled to avoid emitting multiple
diagnostics (e.g., "null dereference") for the same issue. The
problem is that such checks also effect path pruning and don't just
emit diagnostics. This resulted in an assertion failure involving a
real divide-by-zero in some analyzed code where we would get an
assertion failure in APInt because the 'DivZero' check was disabled
and didn't prune the logic that resulted in the divide-by-zero in the
analyzer.
The implemented solution is somewhat of a hack, and may not perform
extremely well. This will need to be cleaned up over time.
As a regression test, 'misc-ps.m' has been modified so that its tests
are run using -fobjc-gc to test this diagnostic pruning behavior.
llvm-svn: 82198
essence, code completion is triggered by a magic "code completion"
token produced by the lexer [*], which the parser recognizes at
certain points in the grammar. The parser then calls into the Action
object with the appropriate CodeCompletionXXX action.
Sema implements the CodeCompletionXXX callbacks by performing minimal
translation, then forwarding them to a CodeCompletionConsumer
subclass, which uses the results of semantic analysis to provide
code-completion results. At present, only a single, "printing" code
completion consumer is available, for regression testing and
debugging. However, the design is meant to permit other
code-completion consumers.
This initial commit contains two code-completion actions: one for
member access, e.g., "x." or "p->", and one for
nested-name-specifiers, e.g., "std::". More code-completion actions
will follow, along with improved gathering of code-completion results
for the various contexts.
[*] In the current -code-completion-dump testing/debugging mode, the
file is truncated at the completion point and EOF is translated into
"code completion".
llvm-svn: 82166
- Doesn't actually work yet because only module level asm's get correctly marked as externally visible in the PCH.
- Other things like 'clang-cc foo.ast -ast-dump' now work, as well.
llvm-svn: 82107
point at the template and print out its template arguments, e.g.,
ambiguous-ovl-print.cpp:5:8: note: candidate function template specialization
[with T = int]
void f(T*, long);
llvm-svn: 81907
generated for an inline function definition, taking into account C99
and GNU inline/extern inline semantics. This solution is simpler,
cleaner, and fixes PR4536.
llvm-svn: 81670
to statically type various methods in SValuator/GRState as required either a
defined value or a defined-but-possibly-unknown value. This leads to various
logic cleanups in GRExprEngine, and lets the compiler enforce via type checking
our assumptions about what symbolic values are possibly undefined and what are
not.
Along the way, clean up some of the static analyzer diagnostics regarding the uses of uninitialized values.
llvm-svn: 81579
instantiation of a member function template or member function of a
class template to be out-of-line if the definition of that function
template or member function was defined out-of-line. This ensures that
we get the correct linkage for explicit instantiations of out-of-line
definitions.
llvm-svn: 81562
- Diagnose attempts to add default arguments to templates (or member
functions of templates) after the initial declaration (DR217).
- Improve diagnostics when a default argument is redefined. Now, the
note will always point at the place where the default argument was
previously defined, rather than pointing to the most recent
declaration of the function.
llvm-svn: 81548
from its location. Initialize appropriately.
When implicitly creating a declaration of a class template specialization
after encountering the first reference to it, use the pattern class's
location instead of the location of the first reference.
llvm-svn: 81515
all of the parent DeclContexts that aren't represented within the
Scope chain. This fixes some name-lookup problems in out-of-line
definitions of members of nested classes.
llvm-svn: 81451
such initializations properly convert constructor arguments and fill
in default arguments where necessary. This also makes the ownership
model more clear.
llvm-svn: 81394
templates, e.g.,
x.template get<T>
We can now parse these, represent them within an UnresolvedMemberExpr
expression, then instantiate that expression node in simple cases.
This allows us to stumble through parsing LLVM's Casting.h.
llvm-svn: 81300
through an array of void*), so that we don't run afoul of the
strict-aliasing rules in C++ 3.10p15. Unfortunately, GCC 4.4 still
complains about this code.
llvm-svn: 81251
ways: remove elab types during desugaring, enhance pretty-printing to allow
tags to be suppressed without suppressing scopes, look through elab types
when associating a typedef name with an anonymous record type.
llvm-svn: 81065
directly in the AST. The current thinking is to create these
only in C++ mode for efficiency. But for now, they're not being
created at all; patch to follow.
This will let us do things like verify that tags match during
template instantation, as well as signal that an elaborated type
specifier was used for clients that actually care.
Optimally, the TypeLoc hierarchy should be adjusted to carry tag
location information as well.
llvm-svn: 81057
templates. We now distinguish between an explicit instantiation
declaration and an explicit instantiation definition, and know not to
instantiate explicit instantiation declarations. Unfortunately, there
is some remaining confusion w.r.t. instantiation of out-of-line member
function definitions that causes trouble here.
llvm-svn: 81053
formed without a trailing '(', diagnose the error (these expressions
must be immediately called), emit a fix-it hint, and fix the code.
llvm-svn: 81015
expressions, e.g.,
p->~T()
when p is a pointer to a scalar type.
We don't currently diagnose errors when pseudo-destructor expressions
are used in any way other than by forming a call.
llvm-svn: 81009
involve qualified names, e.g., x->Base::f. We now maintain enough
information in the AST to compare the results of the name lookup of
"Base" in the scope of the postfix-expression (determined at template
definition time) and in the type of the object expression.
llvm-svn: 80953
t->Base::f
where t has a dependent type. We save the nested-name-specifier in the
CXXUnresolvedMemberExpr then, during instantiation, substitute into
the nested-name-specifier with the (transformed) object type of t, so
that we get name lookup into the type of the object expression.
Note that we do not yet retain information about name lookup into the
lexical scope of the member access expression, so several regression
tests are still disabled.
llvm-svn: 80925
1) Issue digsnostics in non-fragile ABI, when an expression
evaluates to an interface type (except when it is used to
access a non-fragile ivar).
2) Issue unsupported error in fragile ABI when an expression
evaluates to an interface type (except when it is used to
access a fragile ivar).
llvm-svn: 80860
with to properly support member access expressions in templates. This
test is XFAIL'd, because we get it completely wrong, but I've made the
minimal changes to the representation to at least avoid a crash.
llvm-svn: 80856
x->Base::f
We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.
We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.
I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.
llvm-svn: 80843
Also fix a checker context bug: the Dst set is not always empty initially.
Because in GRExprEngine::CheckerVisit(), *CurrSet is used repeatedly.
So we removed the Dst.empty() condition in ~CheckerContext() when deciding
whether to do autotransision.
llvm-svn: 80786
motivated from Shark profiles that shows that 'markLive' was very
heavy when using --analyzer-store=region. On my benchmark file, this
reduces the analysis time for --analyzer-store=region from 19.5s to
13.5s and for --analyzer-store=basic from 5.3s to 3.5s. For the
benchmark file, this is a reduction of about 30% analysis time for
both analysis modes (a huge win).
llvm-svn: 80765
space within the MemberExpr for the nested-name-specifier and its
source range. We'll do the same thing with explicitly-specified
template arguments, assuming I don't flip-flop again.
llvm-svn: 80642
improved if there were a consistent name for getInstantiatedFromMemberX()
across all classes. Cheap refactor if someone wants to do it, but let's get the
buildbots happy first.
llvm-svn: 80425
declarations of same, introduce a single AST class and add appropriate bits
(encoded in the namespace) for whether a decl is "real" or not. Much hackery
about previously-declared / not-previously-declared, but it's essentially
mandated by the standard that friends alter lookup, and this is at least
fairly non-intrusive.
Refactor the Sema methods specific to friends for cleaner flow and less nesting.
Incidentally solve a few bugs, but I remain confident that we can put them back.
llvm-svn: 80353
pointers. Most logic cares first about whether or not a region is
symbolic, and second if represents code. This should fix a series of
silent corner case bugs (as well as simplify a bunch of code).
llvm-svn: 80335
Douglas Gregor