- Docs are fairly sketchy, if someone wants to pore through gcc to look for
holes I'd appreciate any failing test cases!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104809 91177308-0d34-0410-b5e6-96231b3b80d8
any arguments that are default-argument expressions. The can show up
when we have a new expression whose constructor arguments are not
type-dependent and whose allocated type is not dependent and has a
constructor with default arguments. Fixes PR7202.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104690 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostics. That would be while we're parsing string literals for the
sole purpose of producing a diagnostic about them. Fixes
<rdar://problem/8026030>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104684 91177308-0d34-0410-b5e6-96231b3b80d8
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104585 91177308-0d34-0410-b5e6-96231b3b80d8
- I think this can be cleaned up, since this means we may notify the consumer about the vtable twice, but I didn't see an easy fix for this without more substantial refactoring.
- Doug, please review!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104577 91177308-0d34-0410-b5e6-96231b3b80d8
VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (which
would be very bad).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104471 91177308-0d34-0410-b5e6-96231b3b80d8
UnresolvedMemberExpr in their constructors, rather than adding them
after the fact. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104468 91177308-0d34-0410-b5e6-96231b3b80d8
in several important ways:
- VLAs of non-POD types are not permitted.
- VLAs cannot be used in conjunction with C++ templates.
These restrictions are intended to keep VLAs out of the parts of the
C++ type system where they cause the most trouble. Fixes PR5678 and
<rdar://problem/8013618>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104443 91177308-0d34-0410-b5e6-96231b3b80d8
temporaries. There are actually several interrelated fixes here:
- When converting an object to a base class, it's only an lvalue
cast when the original object was an lvalue and we aren't casting
pointer-to-derived to pointer-to-base. Previously, we were
misclassifying derived-to-base casts of class rvalues as lvalues,
causing various oddities (including problems with reference binding
not extending the lifetimes of some temporaries).
- Teach the code for emitting a reference binding how to look
through no-op casts and parentheses directly, since
Expr::IgnoreParenNoOpCasts is just plain wrong for this. Also, make
sure that we properly look through multiple levels of indirection
from the temporary object, but destroy the actual temporary object;
this fixes the reference-binding issue mentioned above.
- Teach Objective-C message sends to bind the result as a temporary
when needed. This is actually John's change, but it triggered the
reference-binding problem above, so it's included here. Now John
can actually test his return-slot improvements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104434 91177308-0d34-0410-b5e6-96231b3b80d8
the required "template" keyword, using the same heuristics we do for
dependent template names in member access expressions, e.g.,
test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
keyword to treat 'getAs' as a dependent template name
T::getAs<U>();
^
template
Fixes PR5404.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104409 91177308-0d34-0410-b5e6-96231b3b80d8
that is missing the 'template' keyword, e.g.,
t->getAs<T>()
where getAs is a member of an unknown specialization. C++ requires
that we treat "getAs" as a value, but that would fail to parse since T
is the name of a type. We would then fail at the '>', since a type
cannot be followed by a '>'.
This is a very common error for C++ programmers to make, especially
since GCC occasionally allows it when it shouldn't (as does Visual
C++). So, when we are in this case, we use tentative parsing to see if
the tokens starting at "<" can only be parsed as a template argument
list. If so, we produce a diagnostic with a fix-it that states that
the 'template' keyword is needed:
test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
is required to treat 'getAs' as a dependent template name
t->getAs<T>();
^
template
This is just a start of this patch; I'd like to apply the same
approach to everywhere that a template-id with dependent template name
can be parsed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104406 91177308-0d34-0410-b5e6-96231b3b80d8
CXXBasePaths::isAmbiguous(), rather than just asserting that we have a
canonical type. Fixes PR7176.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104374 91177308-0d34-0410-b5e6-96231b3b80d8
sure that the anonymous struct/union record declaration gets
instantiated before the variable declaration, and that it and its
fields (recursively) get entries in the local instantiation map. Fixes
PR7088.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104305 91177308-0d34-0410-b5e6-96231b3b80d8
recursively, e.g. so that members of anonymous unions inside anonymous structs
still get initialized. Also generate default constructor calls for anonymous
struct members when necessary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104292 91177308-0d34-0410-b5e6-96231b3b80d8
capture failures when we try to initialize an incomplete
type. Previously, we would (ab)use FK_ConversionFailed, then
occasionally dereference a null pointer when trying to diagnose the
failure. Fixes <rdar://problem/7959007>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104286 91177308-0d34-0410-b5e6-96231b3b80d8
class for UnresolvedLookupExprs, even when occuring on template
names" along with a fix for an Objective-C++ crasher it introduced.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104277 91177308-0d34-0410-b5e6-96231b3b80d8
instance variables:
- Use isRecordType() rather than isa<RecordType>(), so that we see
through typedefs in ivar types.
- Mark the destructor as referenced
- Perform C++ access control on the destructor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104206 91177308-0d34-0410-b5e6-96231b3b80d8
be a copy constructor (since it isn't one semantically)
and fix the ownership bits it sets to be correct!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104192 91177308-0d34-0410-b5e6-96231b3b80d8
create a temporary copy of both the "true" and "false" results. Fixes
the Boost.Interprocess failures.
Daniel did all the hard work of tracking down the issue, I get to type
up the trivial fix for this horrible miscompile.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104184 91177308-0d34-0410-b5e6-96231b3b80d8
template names. We were completely missing naming classes for many unqualified
lookups, but this didn't trigger code paths that need it. This removes part of
an optimization that re-uses the template name lookup done by the parser to
determine if explicit template arguments actually form a template-id.
Unfortunately the technique for avoiding the duplicate lookup lost needed data
such as the class context in which the lookup succeeded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104117 91177308-0d34-0410-b5e6-96231b3b80d8
the same .cpp file as provided the definitions referenced these functions,
hiding the issue. However, they are clearly no longer inline. Let me know if
there is a reason to move their definitions to the header and make them truly
inline.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104104 91177308-0d34-0410-b5e6-96231b3b80d8
involves extending implicit conversion sequences to model vector
conversions and vector splats, along with teaching the C++ conditional
operator-checking code about vector types.
Fixes <rdar://problem/7983501>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104081 91177308-0d34-0410-b5e6-96231b3b80d8
design limitation in how we handle Objective-C class extensions. This was causing the CursorVisitor
to essentially visit an @property twice (once in the @interface, the other in the class extension).
Fixes <rdar://problem/7410145>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104055 91177308-0d34-0410-b5e6-96231b3b80d8
non-function-local declarations with names similar to what the user
typed. For example, this allows us to correct 'supper' to 'super' in
an Objective-C message send, even though the C function 'isupper' has
the same edit distance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104023 91177308-0d34-0410-b5e6-96231b3b80d8
consider "super" as a candidate whenever we're parsing an expression
within an Objective-C method in an interface that has a superclass. At
some point, we'd like to give "super" a little edge over non-local
names; that will come later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104022 91177308-0d34-0410-b5e6-96231b3b80d8
Revert much of the implementation of C++98/03 [temp.friend]p5 in
r103943 and its follow-ons r103948 and r103952. While our
implementation was technically correct, other compilers don't seem to
implement this paragraph (which forces the instantiation of friend
functions defined in a class template when a class template
specialization is instantiated), and doing so broke a bunch of Boost
libraries.
Since this behavior has changed in C++0x (which instantiates the
friend function definitions when they are used), we're going to skip
the nowhere-implemented C++98/03 semantics and go straight to the
C++0x semantics.
This commit is a band-aid to get Boost up and running again. It
doesn't really fix PR6952 (which this commit un-fixes), but it does
deal with the way Boost.Units abuses this particular paragraph.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104014 91177308-0d34-0410-b5e6-96231b3b80d8
If a switch condition is constant, warn if there's no case for it.
Constant switch conditions do come up in reasonable template code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104010 91177308-0d34-0410-b5e6-96231b3b80d8
class template conflicts with an existing (non-template)
definition. This is another part of PR6952.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103948 91177308-0d34-0410-b5e6-96231b3b80d8
within class templates be instantiated along with each class template
specialization, even if the functions are not used. Do so, as a baby
step toward PR6952.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103943 91177308-0d34-0410-b5e6-96231b3b80d8
of an array type, use the outermost array bound as the number of
elements to allocate. Fixes PR7147.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103908 91177308-0d34-0410-b5e6-96231b3b80d8
ObjCObjectType, which is basically just a pair of
one of {primitive-id, primitive-Class, user-defined @class}
with
a list of protocols.
An ObjCObjectPointerType is therefore just a pointer which always points to
one of these types (possibly sugared). ObjCInterfaceType is now just a kind
of ObjCObjectType which happens to not carry any protocols.
Alter a rather large number of use sites to use ObjCObjectType instead of
ObjCInterfaceType. Store an ObjCInterfaceType as a pointer on the decl rather
than hashing them in a FoldingSet. Remove some number of methods that are no
longer used, at least after this patch.
By simplifying ObjCObjectPointerType, we are now able to easily remove and apply
pointers to Objective-C types, which is crucial for a certain kind of ObjC++
metaprogramming common in WebKit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103870 91177308-0d34-0410-b5e6-96231b3b80d8
return statements. We perform NRVO only when all of the return
statements in the function return the same variable. Fixes some link
failures in Boost.Interprocess (which is relying on NRVO), and
probably improves performance for some C++ applications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103867 91177308-0d34-0410-b5e6-96231b3b80d8
return value optimization. Sema marks return statements with their
NRVO candidates (which may or may not end up using the NRVO), then, at
the end of a function body, computes and marks those variables that
can be allocated into the return slot.
I've checked this locally with some debugging statements (not
committed), but there won't be any tests until CodeGen comes along.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103865 91177308-0d34-0410-b5e6-96231b3b80d8
"return" statement and mark the corresponding CXXConstructExpr as
elidable. Teach CodeGen that eliding a temporary is different from
eliding an object construction.
This is just a baby step toward NRVO.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103849 91177308-0d34-0410-b5e6-96231b3b80d8
user directive is needed to force a property implementation.
It is decided based on those propeties which are declared in
the class (or in its protocols) but not those which must be
default implemented by one of its super classes. Implements radar 7923851.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103787 91177308-0d34-0410-b5e6-96231b3b80d8
"used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions.
The new scheme:
- For every use of a vtable, Sema calls MarkVTableUsed() to indicate
the use. For example, this occurs when calling a virtual member
function of the class, defining a constructor of that class type,
dynamic_cast'ing from that type to a derived class, casting
to/through a virtual base class, etc.
- For every definition of a vtable, Sema calls MarkVTableUsed() to
indicate the definition. This happens at the end of the translation
unit for classes whose key function has been defined (so we can
delay computation of the key function; see PR6564), and will also
occur with explicit template instantiation definitions.
- For every vtable defined/used, we mark all of the virtual member
functions of that vtable as defined/used, unless we know that the key
function is in another translation unit. This instantiates virtual
member functions when needed.
- At the end of the translation unit, Sema tells CodeGen (via the
ASTConsumer) which vtables must be defined (CodeGen will define
them) and which may be used (for which CodeGen will define the
vtables lazily).
From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).
Notes:
(1) There's a ton of churn in the tests, because the order in which
vtables get emitted to IR has changed. I've tried to isolate some of
the larger tests from these issues.
(2) Some diagnostics related to
implicitly-instantiated/implicitly-defined virtual member functions
have moved to the point of first use/definition. It's better this
way.
(3) I could use a review of the places where we MarkVTableUsed, to
see if I missed any place where the language effectively requires a
vtable.
Fixes PR7114 and PR6564.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103718 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Dunbar
John McCall
Douglas Gregor
Fariborz Jahanian
Abramo Bagnara
Chris Lattner
Jim Grosbach
Ted Kremenek
Chandler Carruth
Sean Hunt
Eli Friedman
Anders Carlsson