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
typo.cpp:27:8: error: no template named 'basic_sting' in namespace 'std';
did you mean 'basic_string'?
std::basic_sting<char> b2;
~~~~~^~~~~~~~~~~
basic_string
llvm-svn: 92348
typo.cpp:22:10: error: use of undeclared identifier 'radious'; did
you mean 'radius'?
return radious * pi;
^~~~~~~
radius
This was super-easy, since we already had decent recovery by looking
for names in dependent base classes.
llvm-svn: 92341
attach the appropriate attributes to it. I don't think
this manifests as any real change though, we're still
not getting the right LLVM IR attributes out of codegen.
llvm-svn: 92316
tring str2;
we produce the following diagnostic + fix-it:
typo.cpp:15:1: error: unknown type name 'tring'; did you mean 'string'?
tring str2;
^~~~~
string
To make this really useful, we'll need to introduce typo correction in
many more places (wherever we do name lookup), and implement
declaration-vs-expression heuristics that cope with typos
better. However, for now this will handle the simple cases where we
already get good "unknown type name" diagnostics.
The LookupVisibleDecls functions are intended to be used by code
completion as well as typo correction; that refactoring will happen
later.
llvm-svn: 92308
QualType to get CVR-qualifiers through array types, and switches the primary
comparison methods to use it. This may allow simplifying some of the callers of
getUnqualifiedArrayType.
Also fix the normalizing of CV-qualification during template deduction to
normalize through arrays and allow a more qualified deduced array type. This
fixes PR5911.
llvm-svn: 92289
CV-qualifiers. Remove an error expectation from the 'good' set of const-cast
test cases. With this patch, the final non-template test case from PR5542
passes. (It's the same as the one already in const-cast.cpp.)
llvm-svn: 92257
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
address resolution. This fixes PR5751.
Also, while we're here, remove logic from ADL which mistakenly included the
definition namespaces of overloaded and/or templated functions whose name or
address is used as an argument.
llvm-svn: 92245
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
expressions (e.g., for template instantiation), just transform the
subexpressions and return those, since the temporary-related nodes
will be implicitly regenerated. Fixes PR5867, but I said that
before...
llvm-svn: 92135
argument-passing doesn't have to. Fixes PR5867, where we were binding
a temporary twice in the AST and, therefore, calling its destructor
twice.
llvm-svn: 92131
Darwin's sekrit fourth argument. This should probably be factored to
let targets make target-specific decisions about what main() should look like.
Fixes rdar://problem/7414990
or if different platforms have radically different ideas of what they want in
llvm-svn: 92128
that this is true when mangling, then fix up the various places in
Sema and/or CodeGen that need to remove qualifiers. Addresses a
linking issue when building LLVM with Clang.
llvm-svn: 92064
member function thereof), perform the template instantiation each time
the default argument is needed. This ensures that
(1) We get different CXXTemporary objects for each instantiation, and
(2) Any other instantiations or definitions triggered by the
instantiation of the default argument expression are guaranteed to
happen; previously, they might have been suppressed, e.g., because
they happened in an unevaluated context.
This fixes the majority of PR5810. However, it does not address the
problem where we may have multiple uses of the same CXXTemporary
within an expression when the temporary came from a non-instantiated
default argument expression.
llvm-svn: 92015
only takes a boolean second argument now. Update tests accordingly.
Currently the builtin still accepts the full range for compatibility.
llvm-svn: 91983
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
a size, check whether the transformed type is itself an array type. If
so, take the major array bound as the size to allocate. Fixes PR5833.
llvm-svn: 91907
InitializationSequence (when a FunctionDecl is present). This required
a few small fixes to initialization sequences:
- Make sure to use the adjusted parameter type for initialization of
function parameters.
- Implement transparent union calling semantics in C
llvm-svn: 91902
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
constructor call, the conversion is only a standard conversion
sequence if that constructor is a copy constructor. This fixes PR5834
in a semi-lame way, because the "real" fix will be to move over to
InitializationSequence. That will happen "soonish", but not now.
llvm-svn: 91861
explicitly-specified template arguments are enough to determine the
instantiation, and either template argument deduction fails or is not
performed in that context, we can resolve the template-id down to a
function template specialization (so sayeth C++0x
[temp.arg.explicit]p3). Fixes PR5811.
llvm-svn: 91852
not deduce an "overload" type. Such a deduction indicates a failure in
semantic analysis (e.g., PR5811) that currently isn't caught until
code-generation time. This assertions makes it clearer that this
particular issue is a semantic-analysis problem, not a code-gen problem.
llvm-svn: 91844
Sema::getTypeName.
"LookupNestedNameSpecifierName" isn't quite the right kind of lookup, though;
it doesn't ignore namespaces. Someone more familiar with the lookup code
should fix this properly.
llvm-svn: 91809
Because of the rules of base-class lookup* and the restrictions on typedefs, it
was actually impossible for this to cause any problems more serious than the
spurious acceptance of
template <class T> class A : B<A> { ... };
instead of
template <class T> class A : B<A<T> > { ... };
but I'm sure we can all agree that that is a very important restriction which
is well worth making another Parser->Sema call for.
(*) n.b. clang++ does not implement these rules correctly; we are not ignoring
non-type names
llvm-svn: 91792
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
small bug fixes in SemaInit, switch over SemaDecl to use it more often, and
change a bunch of diagnostics which are different with the new initialization
code.
llvm-svn: 91767
InitializationSequence. Specially, switch initialization of a C++
class type (either copy- or direct-initialization).
Also, make sure that we create an elidable copy-construction when
performing copy initialization of a C++ class variable. Fixes PR5826.
llvm-svn: 91750
Avoids an assertion arising during object-argument initialization in overload
resolution. In theory we can resolve this at definition time if the class
hierarchy for the member is fully known.
llvm-svn: 91747
nested-name specifier name.
I accidentally checked in the test case for this in the last commit ---
fortunately, that refactor was inspired by having debugged this problem already,
so I can fix the bug quick (though probably not fast enough for the buildbots).
llvm-svn: 91677
different functions and pick the function at lookup initialization time.
In theory we could actually divide the criteria functions into N different
functions for the N cases, but it's so not worth it.
Among other things, lets us invoke LookupQualifiedName without recomputing
IDNS info every time.
Do some refactoring in SemaDecl to avoid an awkward special case in LQN
that was only necessary for redeclaration testing for anonymous structs/unions ---
which could be done more efficiently with a scoped lookup anyway.
llvm-svn: 91676
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
function in a C++ call using an arbitrary call-expression type.
Actually exploit this to fix the recovery implemented earlier.
The diagnostic is still iffy, though.
llvm-svn: 91538
used as expressions). In dependent contexts, try to recover by doing a lookup
in previously-dependent base classes. We get better diagnostics out, but
unfortunately the recovery fails: we need to turn it into a method call
expression, not a bare call expression. Thus this is still a WIP.
llvm-svn: 91525
InitializationSequence to perform the actual initialization.
Also, introduced the notion of a tree of initialized entities, so that
we can know where an initialization began when dealing with nested
initializations (as occur when performing list initialization). This
will, eventually, be useful for producing better diagnostics when list
initialization fails, because we can show the path from the top-level
object being initialized down to the actual subobject where
initialization failed.
llvm-svn: 91516
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
non-existing 'isa' field of a non-existing struct type
all related to legacy type definition for 'id' which we have
dropped in clang in favor of a built-in type.
(fixes radar 7470820).
llvm-svn: 91455
For hi/odd of an odd-length vector, the last component is undefined. Since
we shuffle with an undef vector, no CodeGen needs to change to support this.
llvm-svn: 91437
Remove isPod() from DenseMapInfo, splitting it out to its own
isPodLike type trait. This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.
llvm-svn: 91422
attribute to function pointers. It also fixes Sema to check function
pointers for the noreturn attribute when checking for fallthrough.
Patch by Chip Davis, with a slight fix to pass the testsuite.
llvm-svn: 91408
- During instantiation, drop default arguments from constructor and
call expressions; they'll be recomputed anyway, and we don't want
to instantiate them twice.
- Rewrote the instantiation of variable initializers to cope with
non-dependent forms properly.
Together, these fix a handful of problems I introduced with the switch
to always rebuild expressions from the source code "as written."
llvm-svn: 91315
implicitly-generated AST nodes. We previously built instantiated nodes
for each of these AST nodes, then passed them on to Sema, which was
not prepared to see already-type-checked nodes (see PR5755). In some
places, we had ugly workarounds to try to avoid re-type-checking
(e.g., in VarDecl initializer instantiation).
Now, we skip implicitly-generated nodes when performing instantiation,
preferring instead to build just the AST nodes that directly reflect
what was written in the source code. This has several advantages:
- We don't need to instantiate anything that doesn't have a direct
correlation to the source code, so we can have better location
information.
- Semantic analysis sees the same thing at template instantiation
time that it would see for a non-template.
- At least one ugly hack (VarDecl initializers) goes away.
Fixes PR5755.
llvm-svn: 91218
in a potentially potentially evaluated context, queue those
diagnostics and only emit them if the context ends up being
potentially evaluated. This completes the fix for PR5761.
llvm-svn: 91213
__builtin_offsetof, passing through an ellipsis) when we're in an
unevaluated context. This is the first part of the fix to PR5761,
which deals with the simple case of an unevaluated context.
llvm-svn: 91210
specializations and class template partial specializations (they're
never named directly). Also, member access expressions only refer to
value declarations (fields, functions, enumerators, etc.) and
Objective-C property declarations; filter out everything else.
llvm-svn: 91133
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
are a couple of O(n^2) operations in this, some analogous to the usual O(n^2)
redeclaration problem and some not. In particular, retroactively removing
shadow declarations when they're hidden by later decls is pretty unfortunate.
I'm not yet convinced it's worse than the alternative, though.
llvm-svn: 91045
new notion of an "initialization sequence", which encapsulates the
computation of the initialization sequence along with diagnostic
information and the capability to turn the computed sequence into an
expression. At present, I've only switched one CheckReferenceInit
callers over to this new mechanism; more will follow.
Aside from (hopefully) being much more true to the standard, the
diagnostics provided by this reference-initialization code are a bit
better than before. Some examples:
p5-var.cpp:54:12: error: non-const lvalue reference to type 'struct
Derived'
cannot bind to a value of unrelated type 'struct Base'
Derived &dr2 = b; // expected-error{{non-const lvalue reference to
...
^ ~
p5-var.cpp:55:9: error: binding of reference to type 'struct Base' to
a value of
type 'struct Base const' drops qualifiers
Base &br3 = bc; // expected-error{{drops qualifiers}}
^ ~~
p5-var.cpp:57:15: error: ambiguous conversion from derived class
'struct Diamond' to base class 'struct Base':
struct Diamond -> struct Derived -> struct Base
struct Diamond -> struct Derived2 -> struct Base
Base &br5 = diamond; // expected-error{{ambiguous conversion from
...
^~~~~~~
p5-var.cpp:59:9: error: non-const lvalue reference to type 'long'
cannot bind to
a value of unrelated type 'int'
long &lr = i; // expected-error{{non-const lvalue reference to type
...
^ ~
p5-var.cpp:74:9: error: non-const lvalue reference to type 'struct
Base' cannot
bind to a temporary of type 'struct Base'
Base &br1 = Base(); // expected-error{{non-const lvalue reference to
...
^ ~~~~~~
p5-var.cpp:102:9: error: non-const reference cannot bind to bit-field
'i'
int & ir1 = (ib.i); // expected-error{{non-const reference cannot
...
^ ~~~~~~
p5-var.cpp:98:7: note: bit-field is declared here
int i : 17; // expected-note{{bit-field is declared here}}
^
llvm-svn: 90992
"integer promotion" type associated with an enum decl, and use this type to
determine which type to promote to. This type obeys C++ [conv.prom]p2 and
is therefore generally signed unless the range of the enumerators forces
it to be unsigned.
Kills off a lot of false positives from -Wsign-compare in C++, addressing
rdar://7455616
llvm-svn: 90965
using value decls; we optimistically assume they won't turn into conflicts.
Teach it to tell the caller *why* the function doesn't overload with the returned
decl; this will be useful for using hiding.
llvm-svn: 90939
pointers thereof) to their corresponding non-noreturn function
types. This conversion is considered an exact match for
overload-resolution purposes. Note that we are a little more strict
that GCC is, because we encode noreturn in the type system, but that's
a Good Thing (TM) because it does not allow us to pretend that
potentially-returning function pointers are non-returning function
pointers.
Fxies PR5620.
llvm-svn: 90913
print exception specifications on function types and
declarations. Fixes <rdar://problem/7450999>.
There is some poor source-location information here, because we don't
track locations of the types in exception specifications. Filed PR5719.
Failures during template instantiation of the signature of a function
or function template have wrong point-of-instantiation location
information. I'll tackle that with a separate commit.
llvm-svn: 90863
into transparent contexts; instead, we'll look into their nearest
enclosing non-transparent contexts further up the stack. Fixes PR5479.
llvm-svn: 90859
horrible isAddressOfOperand hack in TreeTransform, since that syntactic
information is managed by the initial parser callbacks now.
That's enough insomniac commits for one night.
llvm-svn: 90849
DeclContext, so they don't completely disappear from the AST.
I don't particularly like this fix, but I don't see any obviously better way
to deal with it, and I think it's pretty clearly an improvement; comments
welcome.
llvm-svn: 90835
intended. On the first testcase in the bug, we now produce:
cxx-decl.cpp:12:2: error: unexpected ':' in nested name specifier
y:a a2;
^
::
instead of:
t.cc:8:1: error: C++ requires a type specifier for all declarations
x:a a2;
^
t.cc:8:2: error: invalid token after top level declarator
x:a a2;
^
;
t.cc:9:11: error: use of undeclared identifier 'a2'
x::a a3 = a2;
^
llvm-svn: 90713
instantiation, to ensure that we mark class template specilizations as
abstract when we need to and perform checking of abstract classes.
Also, move the checking that determines whether we are creating a
variable of abstract class type *after* we check whether the type is
complete. Otherwise, we won't see when we have an abstract class
template specialization that is implicitly instantiated by this
declaration. This is the "something else" that Sebastian had noted
earlier.
llvm-svn: 90467
temporaries that are within our current evaluation context. That way,
nested evaluation contexts (e.g., within a sizeof() expression) won't
see temporaries from outer contexts. Also, make sure to push a new
evaluation context when instantiating the initializer of a variable;
this may be an unevaluated context or a potentially-evaluated context,
depending on whether it's an in-class initializer or not. Fixes PR5672.
llvm-svn: 90460
overloaded-operator resolution is wildly untested, but the parallel code for
methods seems to satisfy some trivial tests.
Also change some overload-resolution APIs to take a type instead of an expression,
which lets us avoid creating a spurious CXXThisExpr when resolving implicit
member accesses.
llvm-svn: 90410
results in them (which we were doing intentionally as a stopgap). Fix
an DeclContext lookup-table ordering problem which was causing UsingDecls to
show up incorrectly when looking for ordinary results. And oh hey
Clang-Code-Syntax passes now.
llvm-svn: 90367
there's nothing interesting we can say now that we're correctly not requiring
the qualifier to name a known base class in dependent contexts.
Require scope specifiers on member access expressions to name complete types
if they're not dependent; delay lookup when they are dependent.
Use more appropriate diagnostics when qualified implicit member access
expressions find declarations from unrelated classes.
llvm-svn: 90289
implicit member access to a specific declaration, go ahead and create
it as a DeclRefExpr or a MemberExpr (with implicit CXXThisExpr base) as
appropriate. Otherwise, create an UnresolvedMemberExpr or
DependentScopeMemberExpr with a null base expression.
By representing implicit accesses directly in the AST, we get the ability
to correctly delay the decision about whether it's actually an instance
member access or not until resolution is complete. This permits us
to correctly avoid diagnosing the 'problem' of 'MyType::foo()'
where the relationship to the type isn't really known until instantiation.
llvm-svn: 90266
common to both parsing and template instantiation, so that we'll find
overridden virtuals for member functions of class templates when they
are instantiated.
Additionally, factor out the checking for pure virtual functions, so
that it will be executed both at parsing time and at template
instantiation time.
These changes fix PR5656 (for real), although one more tweak
w.r.t. member function templates will be coming along shortly.
llvm-svn: 90241
ValueDecl, because that isn't always the case in ill-formed
code. Diagnose a common mistake (forgetting to provide a template
argument list for a class template, PR5655) and dyn_cast so that we
handle the general problem of referring to a non-value declaration
gracefully.
llvm-svn: 90239
Anders Carlsson