| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
working on new Objective-C array subscripting
syntax. // rdar://13855682
llvm-svn: 181940
|
|
|
|
|
|
|
| |
warning when property-dot syntax is used
with -Wsign-conversion. // rdar://13855394
llvm-svn: 181914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
llvm-svn: 181252
|
|
|
|
|
|
| |
Patch by Robert Wilhelm.
llvm-svn: 181164
|
|
|
|
|
|
|
|
| |
constructor from None
Patch by Robert Wilhelm.
llvm-svn: 181139
|
|
|
|
|
|
|
|
| |
in the parameter of a function definition. Currently,
it crashes in irgen if it is on other than the 1st dimension.
// rdar://13705391
llvm-svn: 180732
|
|
|
|
|
|
|
|
| |
Yes, this came from actual code.
Fixes <rdar://problem/13557053>.
llvm-svn: 179155
|
|
|
|
| |
llvm-svn: 178320
|
|
|
|
|
|
|
|
|
|
|
| |
likely be implicitly truncated:
* All forms of Bitwise-and, bitwise-or, and integer multiplication.
* The assignment form of integer addition, subtraction, and exclusive-or
* The RHS of the comma operator
* The LHS of left shifts.
llvm-svn: 178273
|
|
|
|
|
|
| |
Fixes <rdar://problem/13491605>.
llvm-svn: 177931
|
|
|
|
| |
llvm-svn: 177193
|
|
|
|
|
|
|
|
| |
the enum constant.
This is QoI. Fixes <rdar://problem/13076064>.
llvm-svn: 177190
|
|
|
|
|
|
| |
operations. // rdar://13423975
llvm-svn: 177181
|
|
|
|
| |
llvm-svn: 177163
|
|
|
|
|
|
| |
for integer overflow. // rdar://13423975
llvm-svn: 177162
|
|
|
|
|
|
| |
is non-anonymous or is defined in a typedef of itself.
llvm-svn: 176742
|
|
|
|
|
|
| |
These all appear in comments or (ironically) diagnostics output.
llvm-svn: 176383
|
|
|
|
|
|
| |
Post-commit CR feedback from Jordan Rose regarding r175594.
llvm-svn: 175679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
llvm-svn: 175462
|
|
|
|
| |
llvm-svn: 175331
|
|
|
|
|
|
|
| |
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
llvm-svn: 174768
|
|
|
|
|
|
| |
rdar://13153516
llvm-svn: 174477
|
|
|
|
|
|
| |
This is required to use them in TableGen.
llvm-svn: 173924
|
|
|
|
|
|
|
|
| |
argument to be memset, check for its type to be complete
before calling Context.getTypeSize(PointeeTy) to prevent
crash. // rdar://13081751.
llvm-svn: 173872
|
|
|
|
|
|
| |
commented on and approved by Richard Smith.
llvm-svn: 173377
|
|
|
|
|
|
|
| |
nulls instead of limiting itself to the language-defined "null pointer
constant".
llvm-svn: 173227
|
|
|
|
|
|
| |
reduce stack usage and hopefully bring back the linux x86_64 buildbot.
llvm-svn: 172765
|
|
|
|
|
|
|
|
|
| |
unsequenced operations in the RHS. We don't compare the RHS with the rest of
the expression yet; such checks will need care to avoid diagnosing unsequenced
operations which are both in conditionally-evaluated subexpressions which
actually can't occur together, such as in '(b && ++x) + (!b && ++x)'.
llvm-svn: 172760
|
|
|
|
| |
llvm-svn: 172693
|
|
|
|
|
|
|
| |
expressions which have undefined behavior due to multiple unsequenced
modifications or an unsequenced modification and use of a variable.
llvm-svn: 172690
|
|
|
|
| |
llvm-svn: 172367
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
|
| |
This simplifies some diagnostic logic in checkUnsafeAssignLiteral(),
hopefully making it less error prone.
llvm-svn: 170945
|
|
|
|
|
|
|
|
|
|
| |
Along the way, fix a bug in CheckLiteralKind(), previously in diagnoseObjCLiteralComparison, where we didn't ignore parentheses
in boxed expressions for purpose of classification.
In other words, both @42 and @(42) should be classified as numeric
literals.
llvm-svn: 170931
|
|
|
|
| |
llvm-svn: 170920
|
|
|
|
| |
llvm-svn: 170919
|
|
|
|
| |
llvm-svn: 170903
|
|
|
|
|
|
|
|
|
|
| |
weak reference.
Thanks to Jordan Rose and John McCall for their sage code review.
Fixes <rdar://problem/12569201>.
llvm-svn: 170864
|
|
|
|
|
|
|
|
| |
This is just a minor bit of refactoring, but it is nice cleanup for
the subsequent patch that adds warning support for assigning literals
to weak variables.
llvm-svn: 170863
|
|
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For most cases where a conversion specifier doesn't match an argument,
we usually guess that the conversion specifier is wrong. However, if
the argument is an integer type and the specifier is %C, it's likely
the user really did mean to print the integer as a character.
(This is more common than %c because there is no way to specify a unichar
literal -- you have to write an integer literal, such as '0x2603',
and then cast it to unichar.)
This does not change the behavior of %S, since there are fewer cases
where printing a literal Unicode *string* is necessary, but this could
easily be changed in the future.
<rdar://problem/11982013>
llvm-svn: 169400
|
|
|
|
|
|
|
| |
No functionality change (the test change is a comment only, and the new
functionality can't be tested using the current test).
llvm-svn: 169399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type of a character literal is 'int' in C, but if the user writes a
character /as/ a literal, we should assume they meant it to be a
character and not a numeric value, and thus offer %c as a correction
rather than %d.
There's a special case for multi-character literals (like 'MooV'), which
have implementation-defined value and usually cannot be printed with %c.
These still use %d as the suggestion.
In C++, the type of a character literal is 'char', and so this problem
doesn't exist.
<rdar://problem/12282316>
llvm-svn: 169398
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
|
| |
with a signed fixed type.
<rdar://problem/12780159>.
llvm-svn: 169051
|
|
|
|
| |
llvm-svn: 168340
|
|
|
|
|
|
|
| |
width of an enum with negative values in IntRange. Include a test for
-Wtautological-constant-out-of-range-compare where this had manifested.
llvm-svn: 168126
|
|
|
|
|
|
| |
-Wtautological-constant-out-of-range-compare and added test case.
llvm-svn: 168023
|
|
|
|
|
|
|
|
|
| |
type conversion between integers. This allows the warning to be more accurate.
Also, turned the warning off in an analyzer test. The relavent test cases
are covered by the tests in Sema.
llvm-svn: 167992
|