| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
why the candidate is non-viable. There's a lot we can do to improve this, but
it's a good start. Further improvements should probably be integrated with the
bad-initialization reporting routines.
llvm-svn: 93277
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
ivar name lookup. Fixes pr5986.
llvm-svn: 93271
|
| |
|
|
|
|
|
|
|
|
| |
unevaluated contexts, because they only matter for code that will
actually be evaluated at runtime.
As part of this, I had to extend PartialDiagnostic to support fix-it
hints.
llvm-svn: 93266
|
| |
|
|
|
|
| |
not in an evaluated context. This removes some bogus warnings.
llvm-svn: 93258
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name a template, when they occur in a base-specifier. This is one of
the (few) places where we know for sure that an identifier followed by
a '<' must be a template name, so we can diagnose and recover well:
test/SemaTemplate/dependent-base-classes.cpp:9:16: error: missing
'template'
keyword prior to dependent template name 'T::apply'
struct X1 : T::apply<U> { }; // expected-error{{missing 'template' ...
^
template
test/SemaTemplate/dependent-base-classes.cpp:12:13: error: unknown
template name
'vector'
struct X2 : vector<T> { }; // expected-error{{unknown template name
'vector'}}
^
2 diagnostics generated.
llvm-svn: 93257
|
| |
|
|
| |
llvm-svn: 93256
|
| |
|
|
| |
llvm-svn: 93255
|
| |
|
|
|
|
|
| |
correctly look through arrays to see cv-qualifiers. Also enhances the routine
for doing this to preserve more type sugaring for diagnostics.
llvm-svn: 93252
|
| |
|
|
|
|
|
|
| |
context, do not attempt typo correction. This harms performance (as
Abramo noted) and can cause some amusing errors, as in this new
testcase.
llvm-svn: 93240
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
embedding single space characters. <rdar://problem/7485503>
llvm-svn: 93231
|
| |
|
|
|
|
|
| |
fidelity with which we note them as functions/constructors and templates
thereof. Also will be helpful when reporting bad conversions (next).
llvm-svn: 93224
|
| |
|
|
| |
llvm-svn: 93217
|
| |
|
|
| |
llvm-svn: 93215
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 93205
|
| |
|
|
|
|
| |
non-NULL before looking at the entity itself.
llvm-svn: 93199
|
| |
|
|
|
|
| |
compile LanguageKit, although the resulting code crashes (although not in any of the functions that use VLAs).
llvm-svn: 93198
|
| |
|
|
|
|
|
| |
is not also a typedef-name" actually means. For anyone keeping score,
that's John: 2, Doug: 0.
llvm-svn: 93196
|
| |
|
|
|
|
|
| |
latter may (eventually) perform multiple levels of desugaring (thus
breaking the newly-added tests) and the former is faster. Thanks, John!
llvm-svn: 93192
|
| |
|
|
|
|
|
|
|
| |
they redefine is a class-name but not a typedef-name, per C++0x
[dcl.typedef]p4. The code in the test was valid C++98 and is valid
C++0x, but an unintended consequence of DR56 made it ill-formed in
C++03 (which we were luck enough to implement). Fixes PR5455.
llvm-svn: 93188
|
| |
|
|
|
|
|
| |
function, be sure to adjust the resulting argument type to a pointer
(if necessary). Fixes PR5910 and PR5949.
llvm-svn: 93178
|
| |
|
|
|
|
| |
for all visible conversion functions.
llvm-svn: 93173
|
| |
|
|
| |
llvm-svn: 93168
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
say either "array type" or "function type", whichever it is. No reason
to make the user guess.
llvm-svn: 93164
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
| |
|
|
|
|
|
|
|
|
| |
"ASTContext::getTypeSize() / 8". Replace [u]int64_t variables with CharUnits
ones as appropriate.
Also rename RawType, fromRaw(), and getRaw() in CharUnits to QuantityType,
fromQuantity(), and getQuantity() for clarity.
llvm-svn: 93153
|
| |
|
|
|
|
| |
function. Fixes PR5985.
llvm-svn: 93150
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++ grammatical constructs that show up in top-level (namespace-level)
declarations, member declarations, template declarations, statements,
expressions, conditions, etc. For example, we now provide a pattern
for
static_cast<type>(expr)
when we can have an expression, or
using namespace identifier;
when we can have a using directive.
Also, improves the results of code completion at the beginning of a
top-level declaration. Previously, we would see value names (function
names, global variables, etc.); now we see types, namespace names,
etc., but no values.
llvm-svn: 93134
|
| |
|
|
| |
llvm-svn: 93119
|
| |
|
|
|
|
|
|
|
| |
1. Add helper class for sema checks for target attributes
2. Add helper class for codegen of target attributes
As a proof-of-concept - implement msp430's 'interrupt' attribute.
llvm-svn: 93118
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 92979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
suggestions follow recovery. Additionally, add a note to these
diagnostics which suggests a fix-it for changing the behavior to what
the user probably meant. Examples:
t.cpp:2:9: warning: & has lower precedence than ==; == will be evaluated first
[-Wparentheses]
if (i & j == k) {
^~~~~~~~
( )
t.cpp:2:9: note: place parentheses around the & expression to evaluate it first
if (i & j == k) {
^
( )
t.cpp:14:9: warning: using the result of an assignment as a condition
without
parentheses [-Wparentheses]
if (i = f()) {
~~^~~~~
( )
t.cpp:14:9: note: use '==' to turn this assignment into an equality
comparison
if (i = f()) {
^
==
llvm-svn: 92975
|
| |
|
|
|
|
|
| |
implicitness without losing track of the (logical or actual) location
where "this" would occur in the source.
llvm-svn: 92958
|
| |
|
|
|
|
|
|
|
| |
no viable overloads. Use a different message when the class provides
no operator[] overloads at all; use it for operator(), too.
Partially addresses PR 5900.
llvm-svn: 92894
|
| |
|
|
|
|
|
|
|
|
|
| |
piece of the declaration. The '@' and the 'end' are separate tokens,
and require two SourceLocations to accurately track.
This change was motivated because ObjCContainerDecl::getSourceRange()
would previously not return the entire range of the declaration (the
'end' would be left off).
llvm-svn: 92891
|
| |
|
|
|
|
|
|
| |
we look into a Scope that corresponds to a compound statement whose
scope was combined with the scope of the function that owns it. This
improves typo correction in many common cases.
llvm-svn: 92879
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
corresponding @interface, provide a note showing which interface we're
referring to. This note has the fix-it hint on it.
Also, don't automatically apply fix-it hints for notes. They're meant
to express fix-its that would change semantics.
llvm-svn: 92870
|
| |
|
|
|
|
| |
ASTContext. Fixes <rdar://problem/7495428>.
llvm-svn: 92867
|
| |
|
|
| |
llvm-svn: 92866
|
| |
|
|
| |
llvm-svn: 92862
|
| |
|
|
|
|
|
| |
continuation classes and its original declaration
is imported from a protocol. This fixes radar 7509234.
llvm-svn: 92856
|
| |
|
|
|
|
| |
virtual function has a body inlined in the class
llvm-svn: 92855
|
| |
|
|
|
|
|
|
| |
result for a nested class whose first non-pure virtual member function
has an inline body. Previously, we were checking for the key function
before we had seen the (delayed) inline body.
llvm-svn: 92839
|