This is kindof questionable but seems to do more-or-less the right thing.
This is not a particularly friendly part of the ABI.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134227 91177308-0d34-0410-b5e6-96231b3b80d8
type/expression/template argument/etc. is instantiation-dependent if
it somehow involves a template parameter, even if it doesn't meet the
requirements for the more common kinds of dependence (dependent type,
type-dependent expression, value-dependent expression).
When we see an instantiation-dependent type, we know we always need to
perform substitution into that instantiation-dependent type. This
keeps us from short-circuiting evaluation in places where we
shouldn't, and lets us properly implement C++0x [temp.type]p2.
In theory, this would also allow us to properly mangle
instantiation-dependent-but-not-dependent decltype types per the
Itanium C++ ABI, but we aren't quite there because we still mangle
based on the canonical type in cases like, e.g.,
template<unsigned> struct A { };
template<typename T>
void f(A<sizeof(sizeof(decltype(T() + T())))>) { }
template void f<int>(A<sizeof(sizeof(int))>);
and therefore get the wrong answer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134225 91177308-0d34-0410-b5e6-96231b3b80d8
The fixed implementation is compatible with the implementation both gcc and llvm-gcc use.
rdar://9686430 . (This is the issue that was reported in the thread "[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable".)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134059 91177308-0d34-0410-b5e6-96231b3b80d8
specifiers. Fixes <rdar://problem/9607158>." because it causes false positives
on some code that uses CF toll free bridging.
- I'll let Doug or Ted figure out the right fix here, possibly just to accept
any pointer type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134041 91177308-0d34-0410-b5e6-96231b3b80d8
This was part of Kaelyn's original patch that got dropped while I was
working on it, but after I ran my tests. =/ Sorry.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134039 91177308-0d34-0410-b5e6-96231b3b80d8
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134007 91177308-0d34-0410-b5e6-96231b3b80d8
This is a one line fix here:
+ // Don't print recursive instantiation notes from an instantiation note.
+ Loc = SM.getSpellingLoc(Loc);
While here, fix the testcase to be more precise (it got filecheck'ized
brutally), and fix EmitCaretDiagnostic to be private and to not pass down
the unused 'Level' argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133993 91177308-0d34-0410-b5e6-96231b3b80d8
when the expression source range overlaps the declaration range.
This can happen for C++ constructor expressions whose range generally
include the variable declaration, e.g.:
MyCXXClass foo; // Make sure pointing at 'foo' returns a VarDecl cursor.
rdar://9124499.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133930 91177308-0d34-0410-b5e6-96231b3b80d8
variable declaration that it belongs to.
This can happen for C++ constructor expressions whose range generally
include the variable declaration, e.g.:
MyCXXClass foo; // Make sure we don't annotate 'foo' as a CallExpr cursor.
rdar://9124499.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133929 91177308-0d34-0410-b5e6-96231b3b80d8
for the '(' and ')' around the initializer unless we actually have an
initializer. Fixes PR10197, an issue where we were value-initializing
rather than default-initializing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133913 91177308-0d34-0410-b5e6-96231b3b80d8
of a single if block. This is really annoying to track down and test.
Silly changes to the test case caused it to stop showing up. I wish
there were a more concrete way of asserting that a note attaches to the
intended diagnostic.
This fixes PR10195.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133907 91177308-0d34-0410-b5e6-96231b3b80d8
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133906 91177308-0d34-0410-b5e6-96231b3b80d8
When performing semantic analysis on a member declaration, fix the check for whether we are declaring a function to check for parenthesized declarators, declaration via decltype, etc.
Also fix the semantic check to not treat FuncType* as a function type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133862 91177308-0d34-0410-b5e6-96231b3b80d8
arithmetic on a VLA as 'nsw', per discussion with djg, and
implement pointer arithmetic (other than array accesses) and
pointer subtraction for VLA types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133855 91177308-0d34-0410-b5e6-96231b3b80d8
declaration, determine whether the declaration will end up declaring a
function using semantic criteria (e.g., it will have function type)
rather than purely syntactic criteria (e.g., it has the form of a
function declarator). Fixes <rdar://problem/9670557>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133854 91177308-0d34-0410-b5e6-96231b3b80d8
to turn off warning on those properties which follow Cocoa naming
convention for retaining objects and yet they were not meant for
such purposes. Also, perform consistancy checking for declared
getters of such methods. // rdar://9636091
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133849 91177308-0d34-0410-b5e6-96231b3b80d8
not sizes; so that we use well-typed allocas; and so that we
properly recurse through the full set of variably-modified types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133827 91177308-0d34-0410-b5e6-96231b3b80d8