| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
redefined. There's a FIXME with an apology about why we don't try to
do better here. Fixes <rdar://problem/7513023>.
llvm-svn: 93274
|
| |
|
|
|
|
|
|
| |
I said to myself, self, why don't you go add a couple of parameters to a method
and then fail to use them, and I thought that sounded like a pretty good idea,
so I did it.
llvm-svn: 93233
|
| |
|
|
|
|
|
| |
sequence. Lots of small relevant changes. Fixes some serious problems with
ambiguous conversions; also possibly improves associated diagnostics.
llvm-svn: 93214
|
| |
|
|
|
|
|
|
|
|
| |
were performing name lookup for template names in C/ObjC and always
finding nothing. Turn off such lookup unless we're in C++ mode, along
with the check that determines whether the given identifier is a
"current class name", and assert that we don't make this mistake
again.
llvm-svn: 93207
|
| |
|
|
|
|
|
|
| |
templates. Previously, a little thinko in the code that replaced a
conversion function template with its redeclaration was causing some
very weird lookup behavior.
llvm-svn: 93166
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(C++ [temp.mem]p5-6), which involves template argument deduction based
on the type named, e.g., given
struct X { template<typename T> operator T*(); } x;
when we call
x.operator int*();
we perform template argument deduction to determine that T=int. This
template argument deduction is needed for template specialization and
explicit instantiation, e.g.,
template<> X::operator float*() { /* ... */ }
and when calling or otherwise naming a conversion function (as in the
first example).
This fixes PR5742 and PR5762, although there's some remaining ugliness
that's causing out-of-line definitions of conversion function
templates to fail. I'll look into that separately.
llvm-svn: 93162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not just the viable ones. This is reasonable because the most common use of
deleted functions is to exclude some implicit conversion during calls; users
therefore will want to figure out why some other options were excluded.
Started sorting overload results. Right now it just sorts by location in the
translation unit (after putting viable functions first), but we can do better than
that.
Changed bool OnlyViable parameter to PrintOverloadCandidates to an enum for better
self-documentation.
llvm-svn: 92990
|
| |
|
|
|
|
| |
specifier that we corrected to.
llvm-svn: 92878
|
| |
|
|
|
|
|
| |
pointing to the declaration that we found that has that name (if it is
unique).
llvm-svn: 92877
|
| |
|
|
|
|
| |
virtual function has a body inlined in the class
llvm-svn: 92855
|
| |
|
|
|
|
|
|
|
| |
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.
Adjust a lot of tests.
llvm-svn: 92832
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deterministic and work properly with templates. Once a class that
needs a vtable has been defined, we now do one if two things:
- If the class has no key function, we place the class on a list of
classes whose virtual functions will need to be "marked" at the
end of the translation unit. The delay until the end of the
translation unit is needed because we might see template
specializations of these virtual functions.
- If the class has a key function, we do nothing; when the key
function is defined, the class will be placed on the
aforementioned list.
At the end of the translation unit, we "mark" all of the virtual
functions of the classes on the list as used, possibly causing
template instantiation and other classes to be added to the
list. This gets LLVM's lib/Support/CommandLine.cpp compiling again.
llvm-svn: 92821
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- All classes can have a key function; templates don't change that.
non-template classes when computing the key function.
- We always mark all of the virtual member functions of class
template instantiations.
- The vtable for an instantiation of a class template has weak
linkage.
We could probably use available_externally linkage for vtables of
classes instantiated by explicit instantiation declarations (extern
templates), but GCC doesn't do this and I'm not 100% that the ABI
permits it.
llvm-svn: 92753
|
| |
|
|
| |
llvm-svn: 92367
|
| |
|
|
|
|
| |
covariant. Fixes PR5920.
llvm-svn: 92365
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test/FixIt/typo.cpp:41:15: error: initializer 'base' does not name a non-static
data member or base class; did you mean the base class 'Base'?
Derived() : base(),
^~~~
Base
test/FixIt/typo.cpp:42:15: error: initializer 'ember' does not name a non-static
data member or base class; did you mean the member 'member'?
ember() { }
^~~~~
member
llvm-svn: 92355
|
| |
|
|
|
|
|
| |
not emitting a follow-on error about 'int', which the user
never wrote. PR5924.
llvm-svn: 92339
|
| |
|
|
|
|
|
|
|
|
| |
more or less cv-qualified than another during implicit conversion and overload
resolution ([basic.type.qualifier] p5). Factors the logic out of template
deduction and into the ASTContext so it can be shared.
This fixes several aspects of PR5542, but not all of them.
llvm-svn: 92248
|
| |
|
|
|
|
| |
help for the moment.
llvm-svn: 92165
|
| |
|
|
| |
llvm-svn: 92162
|
| |
|
|
|
|
| |
here affects clang-on-clang.
llvm-svn: 92151
|
| |
|
|
|
|
|
|
| |
keep track of friends within templates, which will provide a real for
PR5866. For now, this makes sure we don't do something entirely stupid
with friends of specializations.
llvm-svn: 92143
|
| |
|
|
| |
llvm-svn: 92137
|
| |
|
|
|
|
|
|
| |
size_t. Also, fix an issue with initialization of parameters in calls,
where we weren't removing the cv-qualifiers on the parameter type
itself. Fixes PR5823.
llvm-svn: 91941
|
| |
|
|
| |
llvm-svn: 91927
|
| |
|
|
| |
llvm-svn: 91883
|
| |
|
|
|
|
|
|
|
| |
this was useful, and on review Doug and I decided it was probably on the level
of a bug in the standard and therefore not worth a warning even in -pedantic.
If someone disagrees and urgently wants clang++ to warn about this in strict
c++98 mode, we can talk about it.
llvm-svn: 91868
|
| |
|
|
|
|
| |
since the context is available in the Decl
llvm-svn: 91862
|
| |
|
|
|
|
| |
support diagnostics and error recovery.
llvm-svn: 91825
|
| |
|
|
|
|
|
| |
the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can
live with that; they'll need to be fixed more holistically anyhow.
llvm-svn: 91771
|
| |
|
|
|
|
|
| |
Magically fixes all the terrible lookup problems associated with not pushing
a new scope. Resolves an ancient xfail and an LLVM misparse.
llvm-svn: 91769
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new InitializationSequence. This fixes some bugs (e.g., PR5808),
changed some diagnostics, and caused more churn than expected. What's
new:
- InitializationSequence now has a "C conversion sequence" category
and step kind, which falls back to
- Changed the diagnostics for returns to always have the result type
of the function first and the type of the expression second.
CheckSingleAssignmentConstraints to peform checking in C.
- Improved ASTs for initialization of return values. The ASTs now
capture all of the temporaries we need to create, but
intentionally do not bind the tempoary that is actually returned,
so that it won't get destroyed twice.
- Make sure to perform an (elidable!) copy of the class object that
is returned from a class.
- Fix copy elision in CodeGen to properly see through the
subexpressions that occur with elidable copies.
- Give "new" its own entity kind; as with return values and thrown
objects, we don't bind the expression so we don't call a
destructor for it.
Note that, with this patch, I've broken returning move-only types in
C++0x. We'll fix it later, when we tackle NRVO.
llvm-svn: 91669
|
| |
|
|
|
|
| |
method overrides a pure virtual method.
llvm-svn: 91558
|
| |
|
|
|
|
|
| |
with a non-trivial default constructor, zero-initialize the storage
and then call the default constructor. Fixes PR5800.
llvm-svn: 91548
|
| |
|
|
| |
llvm-svn: 91503
|
| |
|
|
|
|
| |
standard the last time. Fixes PR5766.
llvm-svn: 91493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
than using its own partial implementation of initialization.
Switched CheckInitializerTypes over to
InitializedEntity/InitializationKind, to help move us closer to
InitializationSequence.
Added InitializedEntity::getName() to retrieve the name of the entity,
for diagnostics that care about such things.
Implemented support for default initialization in
InitializationSequence.
Clean up the determination of the "source expressions" for an
initialization sequence in InitializationSequence::Perform.
Taught CXXConstructExpr to store more location information.
llvm-svn: 91492
|
| |
|
|
| |
llvm-svn: 91450
|
| |
|
|
| |
llvm-svn: 91433
|
| |
|
|
| |
llvm-svn: 91244
|
| |
|
|
| |
llvm-svn: 91204
|
| |
|
|
| |
llvm-svn: 91190
|
| |
|
|
| |
llvm-svn: 91189
|
| |
|
|
| |
llvm-svn: 91187
|
| |
|
|
| |
llvm-svn: 91182
|
| |
|
|
| |
llvm-svn: 91180
|
| |
|
|
| |
llvm-svn: 91119
|
| |
|
|
|
|
|
| |
doing any of the other redeclaration checks. We were missing a few cases.
Fixes PR 5752.
llvm-svn: 91096
|
| |
|
|
|
|
|
|
|
|
|
|
| |
is difficult because they're so terribly, terribly ambiguous.
We implement access declarations in terms of using declarations, which is
quite reasonable. However, we should really persist the access/using
distinction in the AST and use the appropriate name in diagnostics. This
isn't a priority, so I'll just file a PR and hope someone else does it. :)
llvm-svn: 91095
|
| |
|
|
|
|
|
|
| |
declaration. Rename note_using_decl to note_using, which is possibly less confusing.
Add a test for non-class-scope using decl collisions and be sure to note the case
we can't diagnose yet.
llvm-svn: 91057
|