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
(1) Introduce a new 'BindingKey' class to match 'BindingValue'. This
gives us the flexibility to change the current key value from 'const
MemRegion*' to something more interesting.
(2) Rework additions/removals/lookups from the store to use new
'Remove', 'Add', 'Lookup' utility methods.
No "real" functionality change; just prep work and abstraction.
llvm-svn: 93136
incompatible with user-defined literals, specifically with the following form:
0x1p+1
The preprocessing-number token extends only as far as the 'p'; the '+' is not
included. Previously we could get away with this extension as p was an invalid
suffix, but now with user-defined literals, 'p' might well be a valid suffix
and we are forced to consider it as such.
This patch also adds a warning in non-0x C++ modes telling the user that
this extension is incompatible with C++0x that is enabled by default
(previously and with other languages, we warn only with a compliance
option such as -pedantic).
llvm-svn: 93135
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
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
CallExpr/ObjCMessageExpr can be visited in an "lvalue" context if it
returns a struct temporary. Currently the analyzer doesn't reason
about struct temporary returned by function calls, but we shouldn't
crash here either.
llvm-svn: 93081
std::vectors.
- MacroBuilder wraps a raw_ostream so it can easily write to any buffer
supported by raw_ostream.
- MacroBuilder's method take Twines for easy string concatenation (this was done
with sprintf and temporary buffers before).
- Targets still use std::vector as they don't have access to the builder.
llvm-svn: 93051
Ken Dyck