| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 119719
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/bugs/show_bug.cgi?id=8558). This patch fixes it. Thanks to
rjmccall for all the coaching!
Approved by rjmccall
llvm-svn: 119697
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
|
|
|
|
| |
llvm-svn: 119678
|
|
|
|
|
|
|
|
|
| |
-Improve the diagnostic message
-Add some comments
Suggestions by Chris.
llvm-svn: 119594
|
|
|
|
|
|
|
|
|
|
| |
definitions if they take by-value
or return by-value any POD that is larger than some threshold (default is 64 bytes).
Implements rdar://8548050.
llvm-svn: 119583
|
|
|
|
|
|
|
| |
Objective-C message sends, which have only whitespace in their
TypedText chunk. Such results have no purpose.
llvm-svn: 119569
|
|
|
|
|
|
| |
nonofragile-abi2. Fixes //rdar://8673791
llvm-svn: 119543
|
|
|
|
| |
llvm-svn: 119540
|
|
|
|
| |
llvm-svn: 119537
|
|
|
|
|
|
|
|
|
|
|
|
| |
assert(a || b && "bad");
since this is safe. This way we avoid a big source of such warnings which in this case are practically useless.
Note that we don't handle *all* cases where precedence wouldn't matter because of constants since
this is a bit costly to check, and IMO clarifying precedence with parentheses is good for
readability in general.
llvm-svn: 119533
|
|
|
|
|
|
|
| |
on a non-type declaration, as GCC permits it on variables too.
This fixes PR8635.
llvm-svn: 119517
|
|
|
|
|
|
|
|
| |
no longer depends on Preprocessor, so we can move it out of Sema into
a nice new StringLiteral::getLocationOfByte method that can be used by
any AST client.
llvm-svn: 119481
|
|
|
|
|
|
| |
possible to create one without a preprocessor.
llvm-svn: 119476
|
|
|
|
| |
llvm-svn: 119471
|
|
|
|
| |
llvm-svn: 119470
|
|
|
|
|
|
| |
pushing the dependency on the preprocessor out a bit.
llvm-svn: 119468
|
|
|
|
|
|
|
|
|
| |
@synthesize foo = _foo;
keep track of the location of the ivar ("_foo"). Teach libclang to
visit the ivar as a member reference.
llvm-svn: 119447
|
|
|
|
|
|
| |
yet hooked up to anything yet.
llvm-svn: 119407
|
|
|
|
| |
llvm-svn: 119381
|
|
|
|
|
|
|
| |
issue with runtime which I am discussing it with Blaine.
This is wip (so no test yet).
llvm-svn: 119368
|
|
|
|
|
|
|
|
|
|
|
|
| |
producing warnings.
This feels really fragile, and I've not audited all other argument index-based
warnings. I suspect we'll grow this bug on another warning eventually. It might
be nice to adjust the argument indices when building up the attribute AST node,
as we already have to remember about the 'this' argument within that code to
produce correct errors.
llvm-svn: 119340
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
argument indexes. This handles the offsets in a consistent manner for all of
the attributes which I saw working with these concepts. I've also added tests
for the attribute that motivated this: nonnull.
I consolidated the tests for format attributes into one file, and fleshed them
out a bit to trigger more of the warning cases. Also improved the quality of
some of the diagnostics that occur with invalid argument indices.
The only really questionable change here is supporting the implicit this
argument for the ownership attribute. I'm not sure it's really a sensible
concept there, but implemented the logic for consistency.
llvm-svn: 119339
|
|
|
|
|
|
| |
rdar://7743000
llvm-svn: 119336
|
|
|
|
| |
llvm-svn: 119331
|
|
|
|
| |
llvm-svn: 119326
|
|
|
|
| |
llvm-svn: 119316
|
|
|
|
|
|
|
|
| |
to create the special Neon vector types. These are intended to be used in
Clang's version of <arm_neon.h> to define special Neon vector types that will
be mangled according to ARM's ABI.
llvm-svn: 119301
|
|
|
|
| |
llvm-svn: 119298
|
|
|
|
|
|
|
| |
certain internal type-checking procedures as well as for representing
certain implicitly-generated operations. Uses to follow.
llvm-svn: 119289
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
particular, we only add the implement object parameter type if only
one of the function templates is a non-static member function
template.
Moreover, since this DR differs from existing practice in C++98/03,
this commit implements the existing practice (which ignores the
first parameter of the function template that is not the non-static
member function template) in C++98/03 mode.
llvm-svn: 119145
|
|
|
|
| |
llvm-svn: 119141
|
|
|
|
| |
llvm-svn: 119138
|
|
|
|
|
|
|
|
|
|
| |
implicit conversions; the last batch was specific to promotions.
I think this is the full set we need. I do think dividing the cast
kinds into floating and integral is probably a good idea.
Annotate a *lot* more C casts with useful cast kinds.
llvm-svn: 119036
|
|
|
|
|
|
| |
binary operator, provide the types.
llvm-svn: 119008
|
|
|
|
|
|
|
|
|
|
| |
(while computing user conversion sequences), make sure that a result
of class type is a complete class type. Had we gone through
ActOnCallExpr, this would have happened when we built the CallExpr.
Fixes PR8425.
llvm-svn: 119005
|
|
|
|
|
|
| |
between complex types.
llvm-svn: 118994
|
|
|
|
|
|
|
| |
operands appropriately. There are a lot of missing complex-related
cast kinds.
llvm-svn: 118993
|
|
|
|
|
|
|
|
|
|
| |
promoted arithmetic types for which builtin operator candidates are
emitted. A few of these need further analysis.
Removes all the uses of UsualArithmeticConversionsType except the
core function in SemaExpr.cpp.
llvm-svn: 118988
|
|
|
|
|
|
|
| |
instead of copying them all out at the start. Not a significant
optimization.
llvm-svn: 118967
|
|
|
|
| |
llvm-svn: 118966
|
|
|
|
|
|
| |
function templates. Fixes PR8130.
llvm-svn: 118944
|
|
|
|
|
|
|
|
|
| |
parameters to the Transform*Type functions and instead call out
the specific cases where an object type and the unqualified lookup
results are important. Fixes an assert and failed compile on
a testcase from PR7248.
llvm-svn: 118887
|
|
|
|
|
|
|
| |
direct-initialization (rather than copy-initialization) to initialize
the temporary, allowing explicit constructors. Fixes PR8342.
llvm-svn: 118880
|
|
|
|
|
|
|
| |
uncoerced value. Also, whitelist bool bitfields, which aren't
really a truncation.
llvm-svn: 118778
|
|
|
|
|
|
| |
rdar://problem/8652606
llvm-svn: 118773
|
|
|
|
| |
llvm-svn: 118753
|
|
|
|
|
|
| |
a test change, all for blocks. wip.
llvm-svn: 118745
|
|
|
|
|
|
|
|
|
|
|
| |
of the enumerators rather than the actual expressible range. This is
great when dealing with opaque *values* of that type, but when computing
the range of the type for purposes of converting *into* it, it produces
warnings in cases we don't care about (e.g. enum_t x = 500;). Divide
the logic into these two cases and use the more conservative range for
targets.
llvm-svn: 118735
|
|
|
|
|
|
|
|
|
| |
NEON vector types need to be mangled in a special way to comply with ARM's ABI,
similar to some of the AltiVec-specific vector types. This patch is mostly
just renaming a bunch of "AltiVecSpecific" things, since they will no longer
be specific to AltiVec. Besides that, it just adds the new "NeonVector" enum.
llvm-svn: 118724
|