| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74971 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
substitute those template arguments into the function parameter types
prior to template argument deduction. There's still a bit of work to
do to make this work properly when only some of the template arguments
are specified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74576 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.
This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74501 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74390 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
templates.
For example, this now type-checks (but does not instantiate the body
of deref<int>):
template<typename T> T& deref(T* t) { return *t; }
void test(int *ip) {
int &ir = deref(ip);
}
Specific changes/additions:
* Template argument deduction from a call to a function template.
* Instantiation of a function template specializations (just the
declarations) from the template arguments deduced from a call.
* FunctionTemplateDecls are stored directly in declaration contexts
and found via name lookup (all forms), rather than finding the
FunctionDecl and then realizing it is a template. This is
responsible for most of the churn, since some of the core
declaration matching and lookup code assumes that all functions are
FunctionDecls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74213 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function templates. C++ [temp.over.link] paragraphs 4-8.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74079 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
C++. This logic is required to trigger implicit instantiation of
function templates and member functions of class templates, which will
be implemented separately.
This commit includes support for -Wunused-parameter, printing warnings
for named parameters that are not used within a function/Objective-C
method/block. Fixes <rdar://problem/6505209>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73797 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73702 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
involved. Patch by Vyacheslav Kononenko.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
easier than expected because of the limitation that subscript
operators must be member functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71936 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71405 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
into the left-hand side of an assignment expression. This completes
most of PR3500; the only remaining part is to deal with the
GCC-specific implementation-defined behavior for "unsigned long" (and
other) bit-fields.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70623 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
base is a pointer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70562 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
based on a patch from Anders Johnsen. CodeGen support is incomplete,
in that we do not properly coerce to the first field's type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70419 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
general code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69555 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
conversion constructors.
Remove an atrocious amount of trailing whitespace in the overloaded operator mangler. Sorry, couldn't help myself.
Change the DeclType parameter of Sema::CheckReferenceInit to be passed by value instead of reference. It wasn't changed anywhere.
Let the parser handle C++'s irregular grammar around assignment-expression and conditional-expression.
And finally, the reason for all this stuff: implement C++ semantics for the conditional operator. The implementation is complete except for determining lvalueness.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69299 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
different code path that I forgot previously.
Implement the rvalue reference overload dance for returning local objects. Returning a local object first tries to find a move constructor now.
The error message when no move constructor is defined (or is not applicable) and the copy constructor is deleted is quite ugly, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68902 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
crashes codegen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change (really).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68726 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
valgrind complains.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68021 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
failures on i386 or x86_64. If this fails for someone, please contact me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to work around this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67968 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointer. Its purpose in life is to be a glorified void*, but which does not
implicitly convert to void* or other OpaquePtr's with a different UID.
Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>. Change the
entire parser/sema interface to use DeclPtrTy instead of DeclTy*. This
makes the C++ compiler enforce that these aren't convertible to other opaque
types.
We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
but I don't plan to do that in the short term.
The one outstanding known problem with this patch is that we lose the
bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
bitmangle the success bit into the low bit of DeclPtrTy. I will rectify
this with a subsequent patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67952 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SemaCXX//overload-member-call.cpp
SemaCXX//overloaded-operator.cpp
SemaTemplate//instantiate-method.cpp
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67912 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67870 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of "object type" rather than the C definition of "object type". The
difference is that C's "object type" excludes incomplete types such as
struct X;
However, C's definition also makes it far too easy to use isObjectType
as a means to detect incomplete types when in fact we should use other
means (e.g., Sema::RequireCompleteType) that cope with C++ semantics,
including template instantiation.
I've already audited every use of isObjectType and isIncompleteType to
ensure that they are doing the right thing for both C and C++, so this
is patch does not change any functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67648 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67492 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
unclear areas. Maybe Doug can shed some light on some of the fixmes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67059 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
always, refactored the existing logic to tease apart the parser action
and the semantic analysis shared by the parser and template
instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instantiation for binary operators. This change moves most of the
operator-overloading code from the parser action ActOnBinOp to a new,
parser-independent semantic checking routine CreateOverloadedBinOp.
Of particular importance is the fact that CreateOverloadedBinOp does
*not* perform any name lookup based on the current parsing context (it
doesn't take a Scope*), since it has to be usable during template
instantiation, when there is no scope information. Rather, it takes a
pre-computed set of functions that are visible from the context or via
argument-dependent lookup, and adds to that set any member operators
and built-in operator candidates. The set of functions is computed in
the parser action ActOnBinOp based on the current context (both
operator name lookup and argument-dependent lookup). Within a
template, the set computed by ActOnBinOp is saved within the
type-dependent AST node and is augmented with the results of
argument-dependent name lookup at instantiation time (see
TemplateExprInstantiator::VisitCXXOperatorCallExpr).
Sadly, we can't fully test this yet. I'll follow up with template
instantiation for sizeof so that the real fun can begin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66923 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
C++ templates. In particular, keep track of the overloaded operators
that are visible from the template definition, so that they can be
merged with those operators visible via argument-dependent lookup at
instantiation time.
Refactored the lookup routines for argument-dependent lookup and for
operator name lookup, so they can be called without immediately adding
the results to an overload set.
Instantiation of these expressions is completely wrong. I'll work on
that next.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66851 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65671 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types.
Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.
As part of this, some types have been renamed:
TypeOfExpr -> TypeOfExprType
FunctionTypeProto -> FunctionProtoType
FunctionTypeNoProto -> FunctionNoProtoType
There shouldn't be any functionality change...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65591 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65563 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fixes PR3600
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64993 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(as GCC does), except when we've performed overload resolution and
found an unavailable function: in this case, we actually error.
Merge the checking of unavailable functions with the checking for
deprecated functions. This unifies a bit of code, and makes sure that
we're checking for unavailable functions in the right places. Also,
this check can cause an error. We may, eventually, want an option to
make "unavailable" warnings into errors.
Implement much of the logic needed for C++0x deleted functions, which
are effectively the same as "unavailable" functions (but always cause
an error when referenced). However, we don't have the syntax to
specify deleted functions yet :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64955 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
2 out of 2 people on irc prefer them gone :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64749 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- rename isObjCIdType/isObjCClassType -> isObjCIdStructType/isObjCClassStructType. The previous name didn't do what you would expect.
- add back isObjCIdType/isObjCClassType to do what you would expect. Not currently used, however many of the isObjCIdStructType/isObjCClassStructType clients could be converted over time.
- move static Sema function areComparableObjCInterfaces to ASTContext (renamed to areComparableObjCPointerTypes, since it now operates on pointer types).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64385 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
complex conversions where the conversion between the real types is an
integral promotion. This is how G++ handles complex promotions for its
complex integer extension.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64344 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
system. Since C99 doesn't have overloading and C++ doesn't have
_Complex, there is no specification for this. Here's what I think
makes sense.
Complex conversions come in several flavors:
- Complex promotions: a complex -> complex conversion where the
underlying real-type conversion is a floating-point promotion. GCC
seems to call this a promotion, EDG does something else. This is
given "promotion" rank for determining the best viable function.
- Complex conversions: a complex -> complex conversion that is
not a complex promotion. This is given "conversion" rank for
determining the best viable function.
- Complex-real conversions: a real -> complex or complex -> real
conversion. This is given "conversion" rank for determining the
best viable function.
These rules are the same for C99 (when using the "overloadable"
attribute) and C++. However, there is one difference in the handling
of floating-point promotions: in C99, float -> long double and double
-> long double are considered promotions (so we give them "promotion"
rank), while C++ considers these conversions ("conversion" rank).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64343 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This commit adds a new attribute, "overloadable", that enables C++
function overloading in C. The attribute can only be added to function
declarations, e.g.,
int *f(int) __attribute__((overloadable));
If the "overloadable" attribute exists on a function with a given
name, *all* functions with that name (and in that scope) must have the
"overloadable" attribute. Sets of overloaded functions with the
"overloadable" attribute then follow the normal C++ rules for
overloaded functions, e.g., overloads must have different
parameter-type-lists from each other.
When calling an overloaded function in C, we follow the same
overloading rules as C++, with three extensions to the set of standard
conversions:
- A value of a given struct or union type T can be converted to the
type T. This is just the identity conversion. (In C++, this would
go through a copy constructor).
- A value of pointer type T* can be converted to a value of type U*
if T and U are compatible types. This conversion has Conversion
rank (it's considered a pointer conversion in C).
- A value of type T can be converted to a value of type U if T and U
are compatible (and are not both pointer types). This conversion
has Conversion rank (it's considered to be a new kind of
conversion unique to C, a "compatible" conversion).
Known defects (and, therefore, next steps):
1) The standard-conversion handling does not understand conversions
involving _Complex or vector extensions, so it is likely to get
these wrong. We need to add these conversions.
2) All overloadable functions with the same name will have the same
linkage name, which means we'll get a collision in the linker (if
not sooner). We'll need to mangle the names of these functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64336 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-type template parameters that are references to functions or
pointers to member functions. Did a little bit of refactoring so that
these two cases, along with the handling of non-type template
parameters that are pointers to functions, are handled by the same
path.
Also, tweaked FixOverloadedFunctionReference to cope with member
function pointers. This is a necessary step for getting all of the fun
member pointer conversions working outside of template arguments, too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64277 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-type template parameters of pointer-to-object and
pointer-to-function type. The most fun part of this is the use of
overload resolution to pick a function from the set of overloaded
functions that comes in as a template argument.
Also, fixed two minor bugs in this area:
- We were allowing non-type template parameters of type pointer to
void.
- We weren't patching up an expression that refers to an overloaded
function set via "&f" properly.
We're still not performing complete checking of the expression to be
sure that it is referring to an object or function with external
linkage (C++ [temp.arg.nontype]p1).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64266 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
subexpressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64162 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Made allocation of Stmt objects using vanilla new/delete a *compiler
error* by making this new/delete "protected" within class Stmt.
- Now the only way to allocate Stmt objects is by using the new
operator that takes ASTContext& as an argument. This ensures that
all Stmt nodes are allocated from the same (pool) allocator.
- Naturally, these two changes required that *all* creation sites for
AST nodes use new (ASTContext&). This is a large patch, but the
majority of the changes are just this mechanical adjustment.
- The above changes also mean that AST nodes can no longer be
deallocated using 'delete'. Instead, one most do
StmtObject->Destroy(ASTContext&) or do
ASTContextObject.Deallocate(StmtObject) (the latter not running the
'Destroy' method).
Along the way I also...
- Made CompoundStmt allocate its array of Stmt* using the allocator in
ASTContext (previously it used std::vector). There are a whole
bunch of other Stmt classes that need to be similarly changed to
ensure that all memory allocated for ASTs comes from the allocator
in ASTContext.
- Added a new smart pointer ExprOwningPtr to Sema.h. This replaces
the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used
'delete' to free memory instead of a Stmt's 'Destroy' method.
Big thanks to Doug Gregor for helping with the acrobatics of making
'new/delete' private and the new smart pointer ExprOwningPtr!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63997 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63866 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63779 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
into the general name-lookup fold. This cleans up some ugly,
not-quite-working code in the handling of operator overloading.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63735 91177308-0d34-0410-b5e6-96231b3b80d8
|
