clang -cc1 logic for running an action against a set of options.
- This should make it easier to build tools that have a clang -cc1 like
interface, but aren't actually part of clang -cc1.
llvm-svn: 93282
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
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
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
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
initializers. This isn't actually in the C++ grammar (in any version),
but that's clearly an oversight: both GCC and EDG support this syntax,
and it's used within Boost code. I'll file a core issue proposing
precisely the change made here. Fixes PR6008.
llvm-svn: 93243
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
fidelity with which we note them as functions/constructors and templates
thereof. Also will be helpful when reporting bad conversions (next).
llvm-svn: 93224
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
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
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
"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
value bindings. Along with a small change to OSAtomicChecker, this
resolves <rdar://problem/7527292> and resolves some long-standing
issues with how values can be bound to the same physical address by
not have the same "key". This change is only a beginning; logically
RegionStore needs to better handle loads from addresses where the
stored value is larger/smaller/different type than the loaded value.
We handle these cases in an approximate fashion now (via
CastRetrievedVal and help in SimpleSValuator), but it could be made
much smarter.
llvm-svn: 93137
Chris Lattner