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
caught several cases where we were not doing the right thing. I'm
not completely sure all cases are being handled correctly, but this should
be an improvement.
llvm-svn: 92281
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
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
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
variable initializer and the other expressions in an IfStmt.
This change required adding a 'DoDestroy()' method for IfStmt that did
not include destroying the initializer (since that is owned by the
VarDecl).
llvm-svn: 92089
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
used during compilation.
- There is no easy way to define this group properly, unfortunately, and maybe
this is a losing strategy. For now this is unambiguous more friendly, though.
llvm-svn: 91940
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
- Correctly is in quotes, because we are following what I interpreted as GCC's
intent (which diverges from practice, naturally).
- Also, fix the arch define for arm1136jf-s.
llvm-svn: 91855
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
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
Zhongxing Xu