| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 148774
|
|
|
|
|
|
| |
descriptive.
llvm-svn: 148772
|
|
|
|
|
|
| |
matches a typedef declaring an object type. // rdar://10733000
llvm-svn: 148760
|
|
|
|
|
|
|
|
| |
Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.
llvm-svn: 148735
|
|
|
|
|
|
| |
Sema::DiagnoseSentinelCalls() does.
llvm-svn: 148722
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, for unqualified lookups, a positive cache hit is used as the
only non-keyword correction and a negative cache hit immediately returns
an empty TypoCorrection. With the new callback objects, this behavior
causes false negatives by not accounting for the fact that callback
objects alter the set of potential/allowed corrections. The new behavior
is to seed the set of corrections with the cached correction (for
positive hits) to estabilishing a baseline edit distance. Negative cache
hits are only stored or used when either no callback object is provided
or when it returns true for a call to ValidateCandidate with an empty
TypoCorrection (i.e. when ValidateCandidate does not seem to be doing
any checking of the TypoCorrection, such as when an instance of the base
callback class is used solely to specify the set of keywords to be accepted).
llvm-svn: 148720
|
|
|
|
|
|
|
| |
expression) when code-completing member access expressions. Fixes
<rdar://problem/10717172>.
llvm-svn: 148703
|
|
|
|
|
|
|
|
|
| |
to an error, so that users can turn them off if necessary. Note that
this does *not* change the behavior of in a SFINAE context, where we
still flag an error even if the warning is disabled. This matches
GCC's behavior.
llvm-svn: 148701
|
|
|
|
| |
llvm-svn: 148683
|
|
|
|
|
|
| |
This matches cl.exe's behavior and fixes PR11791.
llvm-svn: 148682
|
|
|
|
|
|
|
|
| |
Clang previously implemented -Wswitch-enum the same as -Wswitch. This patch
corrects the behavior to match GCC's. The critical/only difference being that
-Wswitch-enum is not silenced by the presence of a default case in the switch.
llvm-svn: 148679
|
|
|
|
|
|
| |
Also change a || that I accidentally changed to && back to ||.
llvm-svn: 148677
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC2010's pair class has a move assignment operator but no explicit copy
constructor, which makes it unusable without this change.
For symmetry, let move copy constructors not mark the default assignment
operator as deleted either. Both changes match cl.exe's behavior. Fixes
pr11826.
Also update the standard excerpt to point to the right paragraph.
llvm-svn: 148675
|
|
|
|
|
|
| |
appropriate.
llvm-svn: 148673
|
|
|
|
|
|
|
|
|
| |
For consistency with GCC & reasonable sanity. The FIXME suggests that the
original author was perhaps using the default check for some other purpose,
not realizing the more obvious limitation/false-negatives it creates, but this
doesn't seem to produce any regressions & fixes the included test.
llvm-svn: 148649
|
|
|
|
|
|
| |
enumerator that were introduced with r148439. Otherwise MSVC headers won't compile in C++ 11 mode.
llvm-svn: 148642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This warning acts as the complement to the main -Wswitch-enum warning (which
warns whenever a switch over enum without a default doesn't cover all values of
the enum) & has been an an-doc coding convention in LLVM and Clang in my
experience. The purpose is to ensure there's never a "dead" default in a
switch-over-enum because this would hide future -Wswitch-enum errors.
The name warning has a separate flag name so it can be disabled but it's grouped
under -Wswitch-enum & is on-by-default because of this.
The existing violations of this rule in test cases have had the warning disabled
& I've added a specific test for the new behavior (many negative cases already
exist in the same test file - and none regressed - so I didn't add more).
Reviewed by Ted Kremenek ( http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120116/051690.html )
llvm-svn: 148640
|
|
|
|
| |
llvm-svn: 148628
|
|
|
|
|
|
| |
couple of uses of ConstantEvaluated which don't make sense.
llvm-svn: 148624
|
|
|
|
| |
llvm-svn: 148611
|
|
|
|
|
|
| |
correctly, similar to what we already do with typeid.
llvm-svn: 148610
|
|
|
|
|
|
|
| |
argument, which was broken and very ugly (and even had a test case to
make *sure* it was broken and ugly). Fixes <rdar://problem/10609117>.
llvm-svn: 148606
|
|
|
|
| |
llvm-svn: 148595
|
|
|
|
| |
llvm-svn: 148592
|
|
|
|
| |
llvm-svn: 148577
|
|
|
|
| |
llvm-svn: 148549
|
|
|
|
|
|
| |
Found by the clang static analyzer.
llvm-svn: 148544
|
|
|
|
|
|
| |
Found by clang's own static analyzer.
llvm-svn: 148542
|
|
|
|
|
|
| |
and less error-prone way of handling the relevant cases. Towards marking of whether a declaration is used more accurately.
llvm-svn: 148522
|
|
|
|
|
|
| |
constexpr.
llvm-svn: 148505
|
|
|
|
|
|
|
| |
Change CheckVectorLogicalOperands to pass params by ref.
Add another test case.
llvm-svn: 148452
|
|
|
|
| |
llvm-svn: 148441
|
|
|
|
|
|
|
|
|
|
| |
values and non-type template arguments of integral and enumeration types.
This change causes some legal C++98 code to no longer compile in C++11 mode, by
enforcing the C++11 rule that narrowing integral conversions are not permitted
in the final implicit conversion sequence for the above cases.
llvm-svn: 148439
|
|
|
|
|
|
|
|
|
|
|
|
| |
Includes tests highlighting the cases where accuracy has improved
(there is one call that does no filtering beyond selecting the set
of allowed keywords, and one call that only triggers for ObjC code
for which a test by someone who knows ObjC would be welcome). Also
fixes a small typo in one of the suggestion messages, and drops a
malformed "expected-note" for a suggestion that did not occur even
when the malformed note was committed as r145930.
llvm-svn: 148420
|
|
|
|
|
|
|
| |
in favor of usage of api's intended for.
// rdar://8290002
llvm-svn: 148404
|
|
|
|
|
|
|
|
| |
L'x' is actually wchar_t
support C11 u and U char literals
llvm-svn: 148390
|
|
|
|
|
|
|
|
|
|
|
|
| |
No new unit tests yet as there is no behavioral change
(except for slightly more specific filtering in
Sema::ActOnStartOfLambdaDefinition). Tests will be added
as the code paths are traced in greater depth to determine
how to improve the results--there are at least one or two
known bugs that require those improvements. This commit
lays the groundwork for those changes.
llvm-svn: 148382
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for it to be used in converted constant expression checking, and fix a couple
of issues:
- Conversion operators implicitly invoked prior to the narrowing conversion
were not being correctly handled when determining whether a constant value
was narrowed.
- For conversions from floating-point to integral types, the diagnostic text
incorrectly always claimed that the source expression was not a constant
expression.
llvm-svn: 148381
|
|
|
|
|
|
| |
referencing a class field from outside an instance method.
llvm-svn: 148376
|
|
|
|
|
|
| |
inspection.
llvm-svn: 148373
|
|
|
|
|
|
| |
PotentiallyPotentiallyEvaluated contexts. In preparation for making sizeof() PotentiallyPotentiallyEvaluated.
llvm-svn: 148367
|
|
|
|
|
|
|
|
| |
rely on property's type for its life-time to avoid
bogus warning with -Warc-unsafe-retained-assign.
// rdar://10694932
llvm-svn: 148355
|
|
|
|
| |
llvm-svn: 148354
|
|
|
|
|
|
|
|
| |
support. This means you can now write:
for (int i : {1, 4, 512, 23, 251}) {}
llvm-svn: 148353
|
|
|
|
|
|
| |
initializer lists.
llvm-svn: 148352
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are 5 functions of this name in Sema, and 6 more static helpers in
SemaTemplateDeduction.cpp. The Sema functions have jobs like "deduce for
function call", "deduce for taking the address", etc. The static helpers
have jobs like "deduce by comparing two types", "deduce by comparing two
lists of types", "deduce by comparing two template arguments", etc.
The fact that they all are called the same and only differ in two of their
6 or more arguments makes the code using them very hard to read.
Here I rename the one function that concerns me most at the moment, but
as a matter of cleanup, the others will eventually be renamed as well.
llvm-svn: 148351
|
|
|
|
| |
llvm-svn: 148350
|
|
|
|
|
|
| |
This does not yet support CodeGen.
llvm-svn: 148349
|
|
|
|
|
|
| |
operations.
llvm-svn: 148348
|
|
|
|
| |
llvm-svn: 148335
|