| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 194237
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This syntactic checker looks for expressions on both sides of comparison
operators that are structurally the same. As a special case, the
floating-point idiom "x != x" for "isnan(x)" is left alone.
Currently this only checks comparison operators, but in the future we could
extend this to include logical operators or chained if-conditionals.
Checker by Per Viberg!
llvm-svn: 194236
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An Objective-C for-in loop will have zero iterations if the collection is
empty. Previously, we could only detect this case if the program asked for
the collection's -count /before/ the for-in loop. Now, the analyzer
distinguishes for-in loops that had zero iterations from those with at
least one, and can use this information to constrain the result of calling
-count after the loop.
In order to make this actually useful, teach the checker that methods on
NSArray, NSDictionary, and the other immutable collection classes don't
change the count.
<rdar://problem/14992886>
llvm-svn: 194235
|
|
|
|
|
|
|
|
|
|
| |
The path note that says "Loop body executed 0 times" has been changed to
"Loop body skipped when range is empty" for C++11 for-range loops, and to
"Loop body skipped when collection is empty" for Objective-C for-in loops.
Part of <rdar://problem/14992886>
llvm-svn: 194234
|
|
|
|
|
|
|
|
| |
NS_RETURNS_INNER_POINTER ends up unintentionally
on the @property under -objcmt-migrate-all
// rdar://15396636
llvm-svn: 194233
|
|
|
|
|
|
|
|
| |
Produces neater IR in significantly less time.
(~18% faster -O0 compile time for sqlite3 with -fsanitize=undefined)
llvm-svn: 194231
|
|
|
|
| |
llvm-svn: 194229
|
|
|
|
| |
llvm-svn: 194228
|
|
|
|
| |
llvm-svn: 194226
|
|
|
|
|
|
|
|
|
|
|
|
| |
The preprocessor currently recognizes module declarations to load a
module based on seeing the 'import' keyword followed by an
identifier. This sequence is fairly unlikely in C (one would need a
type named 'import'), but is more common in Objective-C (where a
variable named 'import' can cause problems). Since import declarations
currently require a leading '@', recognize that in the preprocessor as
well. Fixes <rdar://problem/15084587>.
llvm-svn: 194225
|
|
|
|
|
|
|
|
|
| |
When performing an Objective-C message send to a value of class type,
perform a contextual conversion to an Objective-C pointer type. We've
had this for a long time, but it recently regressed. Fixes
<rdar://problem/15234703>.
llvm-svn: 194224
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2115
llvm-svn: 194223
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2114
llvm-svn: 194222
|
|
|
|
|
|
|
| |
to avoid breaking AST invariants by reusing Stmt nodes within the same
function.
llvm-svn: 194217
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
#define M(NAME) assert(!Context.Verifying &&#NAME);
After:
#define M(NAME) assert(!Context.Verifying && #NAME);
This fixes llvm.org/PR16156.
llvm-svn: 194216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
[self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa];
[self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa];
After:
[self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa];
[self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa];
This addresses llvm.org/PR15349 and llvm.org/PR16185.
llvm-svn: 194214
|
|
|
|
|
|
| |
forget to clean up temporaries at the end of it.
llvm-svn: 194213
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
Constructor()
: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa(aaaa,
aaaa)) {}
After:
Constructor()
: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaa(aaaa, aaaa)) {}
llvm-svn: 194210
|
|
|
|
|
|
|
|
| |
As a side-effect, constructors definitions will correctly be recognized
and formatted as function declarations. Tests will be added in a
follow-up patch actually using the correct recognition.
llvm-svn: 194209
|
|
|
|
|
|
|
|
| |
obviously >= 0 ;)
Also - others have complained about some white space issues - sorry about that - continues to be a pain point for me - will try and see what I can do with clang-format this evening after work - as a short term fix, if anyone can email me the files that they have already identified with issues, it would help me speed up a focused fix. sorry.
llvm-svn: 194206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
Constructor::Constructor()
: some_value{ //
aaaaaaa //
} {}
After:
Constructor::Constructor()
: some_value{ //
aaaaaaa //
} {}
llvm-svn: 194204
|
|
|
|
|
|
| |
field with a more appropriate name
llvm-svn: 194202
|
|
|
|
| |
llvm-svn: 194200
|
|
|
|
|
|
| |
Add its support in Clang
llvm-svn: 194198
|
|
|
|
| |
llvm-svn: 194197
|
|
|
|
| |
llvm-svn: 194190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks.
What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing.
As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable.
Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas. What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda.
Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming.
This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being:
- generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ...
- nested variadic expansions such as:
auto K = [](auto ... OuterArgs) {
vp([=](auto ... Is) {
decltype(OuterArgs) OA = OuterArgs;
return 0;
}(5)...);
return 0;
};
auto M = K('a', ' ', 1, " -- ", 3.14);
currently cause crashes. I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard.
A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless!
Now let's hope this commit doesn't upset the buildbot gods ;)
Thanks!
llvm-svn: 194188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Similar to __FUNCTION__, MSVC exposes the name of the enclosing mangled
function name via __FUNCDNAME__. This implementation is very naive and
unoptimized, it is expected that __FUNCDNAME__ would be used rarely in
practice.
Reviewers: rnk, rsmith, thakis
CC: cfe-commits, silvas
Differential Revision: http://llvm-reviews.chandlerc.com/D2109
llvm-svn: 194181
|
|
|
|
|
|
| |
No functional changes (intended).
llvm-svn: 194179
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These allow clients to retrieve persistent AST objects (ASTUnits) which
can be used in an ad-hoc manner after parsing.
To accommodate this change, the code for processing a CompilerInvocation
using a FrontendAction has been factored out to FrontendActionFactory, and
a new base class, ToolAction, has been introduced, allowing the tool to do
arbitrary things with each CompilerInvocation. This change was necessary
because ASTUnit does not use the FrontendAction interface directly.
This change also causes the FileManager in ClangTool to use shared ownership.
This will become necessary because ASTUnit takes shared ownership of
FileManager (ClangTool's FileManager is currently unused by ASTUnit; this
is a FIXME). As shown in the tests, any client of ToolInvocation will
need to be modified to use shared ownership for FileManager.
Differential Revision: http://llvm-reviews.chandlerc.com/D2097
llvm-svn: 194164
|
|
|
|
| |
llvm-svn: 194162
|
|
|
|
|
|
|
| |
follow when building a class member access expression. Based on a patch by
Rahul Jain!
llvm-svn: 194161
|
|
|
|
|
|
|
|
|
|
| |
On the microsoft ABI clang is producing one weak_odr and one linkonce_odr
destructor, which is reasonable since only one is required.
The fix is simply to move the assert past the special case treatment of
linkonce_odr.
llvm-svn: 194158
|
|
|
|
|
|
| |
test case.
llvm-svn: 194157
|
|
|
|
|
|
| |
when they actually do.
llvm-svn: 194156
|
|
|
|
| |
llvm-svn: 194132
|
|
|
|
| |
llvm-svn: 194124
|
|
|
|
| |
llvm-svn: 194119
|
|
|
|
|
|
|
| |
earlier 'non-constant' diagnostic with a later one if the earlier one was from
a side-effect we thought we could evaluate past.
llvm-svn: 194117
|
|
|
|
|
|
|
|
|
|
| |
bitfield
This patch adds the same behavior to clang.
Differential Revision: http://llvm-reviews.chandlerc.com/D2103
llvm-svn: 194115
|
|
|
|
|
|
|
|
|
| |
These functions can generally be applied to multiple kinds of AST node,
so it makes sense to add them to DynTypedNode.
Differential Revision: http://llvm-reviews.chandlerc.com/D2096
llvm-svn: 194113
|
|
|
|
|
|
| |
on smart pointers. -Wthread-safety-beta only.
llvm-svn: 194103
|
|
|
|
|
|
|
|
| |
NS_RETURNS_INNER_POINTER under -objcmt-returns-innerpointer-property
flag (off by default), as older compilers do not support such annotations.
// rdar://15396636
llvm-svn: 194100
|
|
|
|
|
|
| |
checking an expression for constant overflow.
llvm-svn: 194099
|
|
|
|
|
|
|
|
|
| |
bit more robust against future changes. This includes a slight diagnostic
improvement: if we know we're only trying to form a constant expression, take
the first diagnostic which shows the expression is not a constant expression,
rather than preferring the first one which makes the expression unfoldable.
llvm-svn: 194098
|
|
|
|
|
|
|
|
|
|
|
| |
hack of passing -fconst-strings to -cc1, but at least the driver uses
the regular warning checking code path.
Since we don't support a warning that is DefaultIgnore in one language
but not in another, this patch creates a dummy C only warning in the same
group as the existing one to get the desired effect.
llvm-svn: 194097
|
|
|
|
|
|
|
| |
This is a small optimization on linux, but should help more on windows
where msvc only outputs one destructor if there would be two identical ones.
llvm-svn: 194095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, clang-format would always format entire nested blocks, which
can be unwanted e.g. for long DEBUG({...}) statements. Also
clang-format would not allow to merge lines in nested blocks (e.g. to
put "if (a) return;" on one line in Google style).
This is the first step of several refactorings mostly focussing on the
additional functionality (by reusing the "format many lines" code to
format the children of a nested block). The next steps are:
* Pull out the line merging into its own class.
* Seperate the formatting of many lines from the formatting of a single
line (and the analysis of the solution space).
llvm-svn: 194090
|
|
|
|
|
|
|
| |
Revert this patch until cases of rejected valid code (e.g. identifiers
that require ADL to be resolved properly) are fixed.
llvm-svn: 194088
|
|
|
|
| |
llvm-svn: 194086
|