template void f<int>(int);
~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82806 91177308-0d34-0410-b5e6-96231b3b80d8
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82789 91177308-0d34-0410-b5e6-96231b3b80d8
value-dependent. Audit (and fixed) all calls to
Expr::isNullPointerConstant() to provide the correct behavior with
value-dependent expressions. Fixes PR5041 and a crash in libstdc++
<locale>.
In the same vein, properly compute value- and type-dependence for
ChooseExpr. Fixes PR4996.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82748 91177308-0d34-0410-b5e6-96231b3b80d8
complete (or, possibly causing template instantiation).
Test this via some explicit specializations of member functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82732 91177308-0d34-0410-b5e6-96231b3b80d8
first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks
There are many caveats here:
- We completely and totally drop any explicitly-specified template
arguments on the floor
- We don't diagnose any of the extra semantic things that we should
diagnose.
- I haven't looked to see that we're getting the right linkage for
explicit specializations
On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82728 91177308-0d34-0410-b5e6-96231b3b80d8
Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right; many more remain.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82705 91177308-0d34-0410-b5e6-96231b3b80d8
have the iterators and operator[] handle the traversal of statements, as they
are stored in reverse order. Tests show this has no real performance impact, but
it does simply the CFG construction logic and will make it slightly easier to
change the allocation strategy for CFGBlocks (as we have fewer copies).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82702 91177308-0d34-0410-b5e6-96231b3b80d8
handled correctly.
- <rdar://problem/7247671> Function arguments incorrect when function returns a
struct on i386 w/ llvm-g++ and clang
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82681 91177308-0d34-0410-b5e6-96231b3b80d8
The issue was a discrepancy between how RegionStoreManager::Bind() and
RegionStoreManager::Retrieve() derived the "key" for the first element
of a symbolic region.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82680 91177308-0d34-0410-b5e6-96231b3b80d8
lookup in a member access expression always start a
nested-name-specifier. Additionally, rank names that start
nested-name-specifiers after other names.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82663 91177308-0d34-0410-b5e6-96231b3b80d8
It uses a recent API to find inherited conversion functions to do
the initializer to reference lvalue conversion (and removes a FIXME).
It issues the ambiguity diagnostics when multiple conversions are found.
WIP.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82649 91177308-0d34-0410-b5e6-96231b3b80d8
that there is one more argument (the one following the comma) and make
the candidate non-viable if the function cannot accept any argument in
that position.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82625 91177308-0d34-0410-b5e6-96231b3b80d8
results for other, textual completion. For call completion, we now
produce enough information to show the function call argument that we
are currently on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82592 91177308-0d34-0410-b5e6-96231b3b80d8
the start of a nested-name-specifier, add the "::" after the
nested-name-specifier to the code-completion string.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82587 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82586 91177308-0d34-0410-b5e6-96231b3b80d8
-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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82571 91177308-0d34-0410-b5e6-96231b3b80d8
notation. There is still an issue accessing field of a 'Class''s isa
in legacy code using dot field access notation (as noted in the test case)
but unrelated to this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82555 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82549 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82501 91177308-0d34-0410-b5e6-96231b3b80d8
integer pointer. For now just invalidate the fields of the struct.
This addresses: <rdar://problem/7185607> [RegionStore] support invalidation of bit fields using integer assignment
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82492 91177308-0d34-0410-b5e6-96231b3b80d8
a nested-name-specifier that describes how to refer to that name. For
example, given:
struct Base { int member; };
struct Derived : Base { int member; };
the code-completion result for a member access into "Derived" will
provide both "member" to refer to Derived::member (no qualification needed) and
"Base::member" to refer to Base::member (qualification included).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82476 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82474 91177308-0d34-0410-b5e6-96231b3b80d8
real work is performed within Sema. Addresses Chris's comments, but
still retains the heavyweight list-of-multimaps data structure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82459 91177308-0d34-0410-b5e6-96231b3b80d8
"->", or "::" if we will be looking into a dependent context. It's not
wrong to use the "template" keyword, but it's to needed, either.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82307 91177308-0d34-0410-b5e6-96231b3b80d8
template smarter, by taking into account which function template
parameters are deducible from the call arguments. For example,
template<typename RandomAccessIterator>
void sort(RandomAccessIterator first, RandomAccessIterator last);
will have a code-completion string like
sort({RandomAccessIterator first}, {RandomAccessIterator last})
since the template argument for its template parameter is
deducible. On the other hand,
template<class X, class Y>
X* dyn_cast(Y *Val);
will have a code-completion string like
dyn_cast<{class X}>({Y *Val})
since the template type parameter X is not deducible from the function
call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82306 91177308-0d34-0410-b5e6-96231b3b80d8
r82198 and then reverted. This is an intermediate solution, as diagnostic
caching should not rely on static variables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82301 91177308-0d34-0410-b5e6-96231b3b80d8
results of code completion, e.g., by providing function call syntax
with placeholders for each of the parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82293 91177308-0d34-0410-b5e6-96231b3b80d8
- 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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82251 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82231 91177308-0d34-0410-b5e6-96231b3b80d8
Fix error in _mm_set_pd/_mm_setr_pd and add _mm_set_epi64x/_mm_set1_epi64x. Patch by Laurent Morichetti!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82228 91177308-0d34-0410-b5e6-96231b3b80d8
results when there is some way to refer to them in the language, such
as with a qualified name in C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82223 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82222 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82201 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82198 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82166 91177308-0d34-0410-b5e6-96231b3b80d8
- Patch by Shantonu Sen!
<rdar://problem/6922650> clang doesn't know about ARM registers for inline asm clobber lists
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82132 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes some bad -O0 codegen and the unnecessary clearing of al on entry to objc_msgSend for most message sends.
<rdar://problem/7102824> [irgen] unnecessary xorb on calls to objc_msgSend on x86_64
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82118 91177308-0d34-0410-b5e6-96231b3b80d8
This still isn't perfect, but I believe it is conservatively accurate at marking decls which IRgen needs to see, while still keeping the "deserialization footprint" on Cocoa.h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82112 91177308-0d34-0410-b5e6-96231b3b80d8
This is something of a hack, since whether the reader actually did this depends on the "isConsumerInterestedIn" predicate. I think we need to rework how this works, but I need to discuss with Doug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82111 91177308-0d34-0410-b5e6-96231b3b80d8
GC. Currently, new API will be generated under
clang-cc's -fobjc-newgc-api flag which will eventually
become the default. WIP.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82082 91177308-0d34-0410-b5e6-96231b3b80d8
when we are not instantiating the corresponding "current
instantiation." This happens, e.g., when we are instantiating a
declaration reference that refers into the "current instantiation" but
occurs in a default function argument. The libstdc++ vector default
constructor now instantiates properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82069 91177308-0d34-0410-b5e6-96231b3b80d8
give them the appropriate exception specifications. This,
unfortunately, requires us to maintain and/or implicitly generate
handles to namespace "std" and the class "std::bad_alloc". However,
every other approach I've come up with was more hackish, and this
standard requirement itself is quite the hack.
Fixes PR4829.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81939 91177308-0d34-0410-b5e6-96231b3b80d8
to pointer function for delete expression. 2)
Treat type conversion function and its 'const' version
as identical in building the visible conversion list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81930 91177308-0d34-0410-b5e6-96231b3b80d8
whether a constructor is a copy constructor.
Sadly, I wasn't able to get down to a test case smaller than libstdc++'s
<string>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81913 91177308-0d34-0410-b5e6-96231b3b80d8
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);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81907 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Anders Carlsson
Fariborz Jahanian
Mike Stump
Benjamin Kramer
Ted Kremenek
John McCall
Daniel Dunbar
Chris Lattner
Nick Lewycky