| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
for __unknown_anytype resolution to destructively modify the AST. So that's
what it does now, which significantly simplifies some of the implementation.
Normal member calls work pretty cleanly now, and I added support for
propagating unknown-ness through &.
llvm-svn: 129331
|
|
|
|
| |
llvm-svn: 129269
|
|
|
|
|
|
| |
and move a vector-splat check to follow l-value conversion.
llvm-svn: 129254
|
|
|
|
|
|
| |
for them. The only major missing feature is references.
llvm-svn: 129234
|
|
|
|
|
|
| |
pageexec@freemail.hu, tweaks by me.
llvm-svn: 129206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
|
|
|
|
|
|
| |
implicit cast for scalars.
llvm-svn: 129066
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use. I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.
llvm-svn: 129065
|
|
|
|
| |
llvm-svn: 129017
|
|
|
|
|
|
| |
a note with a location for the function prototype.
llvm-svn: 128833
|
|
|
|
|
|
| |
Add a test case for synthesize ivar. // rdar://9070460
llvm-svn: 128554
|
|
|
|
|
|
| |
type-dependent expressions. Fixes rdar://9027658.
llvm-svn: 128437
|
|
|
|
|
|
|
| |
an executable test to llvm test suite.
// rdar://9070460.
llvm-svn: 128435
|
|
|
|
| |
llvm-svn: 128427
|
|
|
|
|
|
| |
AltiVec vector types. It fixes bug 9347.
llvm-svn: 128381
|
|
|
|
|
|
| |
PIM section 2.5.1 - after initialization all elements have the value specified by the literal
llvm-svn: 128375
|
|
|
|
|
|
|
|
| |
returned
from an objective-c message: // rdar://9005189
llvm-svn: 128348
|
|
|
|
|
|
| |
without a warning.
llvm-svn: 128328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
|
|
|
|
|
|
|
| |
on previous block parameters that crept in as part of my captures
work a month or so ago.
llvm-svn: 128121
|
|
|
|
|
|
|
|
|
| |
overload, so that we actually do the resolution for full expressions
and emit more consistent, useful diagnostics. Also fixes an IRGen
crasher, where Sema wouldn't diagnose a resolvable bound member
function template-id used in a full-expression (<rdar://problem/9108698>).
llvm-svn: 127747
|
|
|
|
|
|
|
|
|
| |
operands to a binary expression; it doesn't make sense in all
contexts. The right answer would be to see if the user forgot at ().
Fixes <rdar://problem/9136502>.
llvm-svn: 127740
|
|
|
|
|
|
| |
pointer-to-function type. Fixes <rdar://problem/9065289>.
llvm-svn: 127739
|
|
|
|
|
|
|
|
| |
declaration as this results in a confusing error message,
instead of message related to missing property declaration.
// rdar://9106929
llvm-svn: 127682
|
|
|
|
| |
llvm-svn: 127536
|
|
|
|
|
|
| |
should be resolvable, from Faisal Vali!
llvm-svn: 127521
|
|
|
|
|
|
| |
without cl_khr_fp64, warn and cast to single precision
llvm-svn: 127476
|
|
|
|
|
|
|
| |
extending the existing support for sizeof and alignof. Original
patch by Guy Benyei.
llvm-svn: 127475
|
|
|
|
|
|
| |
pointer instead of the other operand.
llvm-svn: 127458
|
|
|
|
| |
llvm-svn: 127225
|
|
|
|
|
|
|
| |
in case we want to make a world where we can check intermediate instantiations
for this kind of breadcrumb.
llvm-svn: 127221
|
|
|
|
| |
llvm-svn: 127217
|
|
|
|
| |
llvm-svn: 127061
|
|
|
|
| |
llvm-svn: 126770
|
|
|
|
|
|
| |
accesses in ?: expressions.
llvm-svn: 126766
|
|
|
|
| |
llvm-svn: 126762
|
|
|
|
| |
llvm-svn: 126752
|
|
|
|
|
|
| |
MemberExpr, the last of the expressions with qualifiers!
llvm-svn: 126688
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UnresolvedLookupExpr and UnresolvedMemberExpr.
Also, improve the computation that checks whether the base of a member
expression (either unresolved or dependent-scoped) is implicit. The
previous check didn't cover all of the cases we use in our
representation, which threw off source-location information for these
expressions (which, in turn, caused some breakage in libclang's token
annotation).
llvm-svn: 126681
|
|
|
|
|
|
|
|
| |
CXXDependentScopeMemberExpr, and clean up instantiation of
nested-name-specifiers with dependent template specialization types in
the process.
llvm-svn: 126663
|
|
|
|
|
|
|
| |
don't let calls to such functions go down the normal type-checking path.
Test this out with __builtin_classify_type and __builtin_constant_p.
llvm-svn: 126539
|
|
|
|
|
|
|
|
| |
don't seem to have been covered by our tests previously.
This should fix bootstrap failure.
llvm-svn: 126345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions. Consider the code:
int64_t i = 10 << 30;
This compiles fine, but most developers expect it to produce the value
for 10 gigs, not -2 gigs. This is actually undefined behavior because
the LHS is a signed integer type.
The warning is currently gated behind -Wshift-overflow.
There is a special case where only the sign bit is overridden that gets
a custom error message and is by default ignored. This case is much less
likely to cause observed buggy behavior, it's just undefined behavior
according to the spec. This warning can be enabled with
-Wshift-sign-overflow.
Original patch by Oleg Slezberg, with style tweaks and some correctness
fixes by me.
llvm-svn: 126342
|
|
|
|
| |
llvm-svn: 126292
|
|
|
|
|
|
|
|
|
|
| |
related code is reachable. This suppresses some
diagnostics that occur in unreachable code (e.g., -Warray-bound).
We only pay the cost of doing the reachability analysis when we issue one of these diagnostics.
llvm-svn: 126290
|
|
|
|
|
|
| |
Sema::PopBlockOrFunctionScope(). No real functionality change.
llvm-svn: 126287
|
|
|
|
|
|
|
|
|
| |
code the diagnostic is associated with.
This Stmt* is unused, but we will use it shortly for pruning diagnostics associated
with unreachable code.
llvm-svn: 126286
|
|
|
|
|
|
|
| |
mostly just shuffles various possibilities for recovery into a more
straightforward order, but also unifies a couple of diagnostics.
llvm-svn: 126266
|
|
|
|
|
|
|
|
| |
* Flag indicating 'we're parsing this auto typed variable's initializer' moved from VarDecl to Sema
* Temporary template parameter list for auto deduction is now allocated on the stack.
* Deduced 'auto' types are now uniqued.
llvm-svn: 126139
|
|
|
|
|
|
|
|
| |
initializers just because they don't have a proper out-of-line definition.
Such code is technically ill-formed but is too common and too unlikely to be
a problem to be seriously worth worrying about.
llvm-svn: 126137
|