Chad Rosier [Wed, 17 Aug 2011 18:24:55 +0000 (18:24 +0000)]
[driver] Clang doesn't support -mkernel/-fapple-kext for i386, so it's
automatically invoking llvm-gcc's cc1plus, which doesn't support all options
supported by Clang. Therefore, filter out unsupported options.
rdar://9964354
Chandler Carruth [Wed, 17 Aug 2011 09:49:44 +0000 (09:49 +0000)]
Whitelist operator== and operator!= as valid for unused value warnings,
even when overloaded and user-defined. These operators are both more
valuable to warn on (due to likely typos) and extremely unlikely to be
reasonable for use to trigger side-effects.
Chandler Carruth [Wed, 17 Aug 2011 09:34:37 +0000 (09:34 +0000)]
Treating the unused equality comparisons as something other than part of
-Wunused was a mistake. It resulted in duplicate warnings and lots of
other hacks. Instead, this should be a special sub-category to
-Wunused-value, much like -Wunused-result is.
Moved to -Wunused-comparison, moved the implementation to piggy back on
the -Wunused-value implementation instead of rolling its own, different
mechanism for catching all of the "interesting" statements.
I like the unused-value mechanism for this better, but its currently
missing several top-level statements. For now, I've FIXME-ed out those
test cases. I'll enhance the generic infrastructure to catch these
statements in a subsequent patch.
This patch also removes the cast-to-void fixit hint. This hint isn't
available on any of the other -Wunused-value diagnostics, and if we want
it to be, we should add it generically rather than in one specific case.
Chandler Carruth [Wed, 17 Aug 2011 08:38:11 +0000 (08:38 +0000)]
Don't suggest assignment in implausible situation. We still warn, as the
code is very likely to be buggy, but its going to require more
significant changes on the part of the user to correct it in this case.
Chandler Carruth [Wed, 17 Aug 2011 08:38:04 +0000 (08:38 +0000)]
Introduce a new warning, -Wtop-level-comparison. This warning is
a complement to the warnings we provide in condition expressions. Much
like we warn on conditions such as:
int x, y;
...
if (x = y) ... // Almost always a typo of '=='
This warning applies the complementary logic to "top-level" statements,
or statements whose value is not consumed or used in some way:
int x, y;
...
x == y; // Almost always a type for '='
We also mirror the '!=' vs. '|=' logic.
The warning is designed to fire even for overloaded operators for two reasons:
1) Especially in the presence of widespread templates that assume
operator== and operator!= perform the expected comparison operations,
it seems unreasonable to suppress warnings on the offchance that
a user has written a class that abuses these operators, embedding
side-effects or other magic within them.
2) There is a trivial source modification to silence the warning for
truly exceptional cases:
(void)(x == y); // No warning
A (greatly reduced) form of this warning has already caught a number of
bugs in our codebase, so there is precedent for it actually firing. That
said, its currently off by default, but enabled under -Wall.
There are several fixmes left here that I'm working on in follow-up
patches, including de-duplicating warnings from -Wunused, sharing code
with -Wunused's implementation (and creating a nice place to hook
diagnostics on "top-level" statements), and handling cases where a proxy
object with a bool conversion is returned, hiding the operation in the
cleanup AST nodes.
Suggestions for any of this code more than welcome. Also, I'd really
love suggestions for better naming than "top-level".
If we pass it a source location that points inside a function macro argument,
the returned location will be the macro location in which the argument was expanded.
If a macro argument is used multiple times, the expanded location will
be at the first expansion of the argument.
e.g.
MY_MACRO(foo);
^
Passing a file location pointing at 'foo', will yield a macro location
where 'foo' was expanded into.
Make SourceManager::getLocation call getMacroArgExpandedLocation as well.
Jordy Rose [Tue, 16 Aug 2011 21:24:21 +0000 (21:24 +0000)]
[analyzer] Overhaul of checker registration in preparation for basic plugin support. Removes support for checker groups (we can add them back in later if we decide they are still useful), and -analyzer-checker-help output is a little worse for the time being (no packages).
Ted Kremenek [Tue, 16 Aug 2011 10:57:37 +0000 (10:57 +0000)]
[analyzer] Enhance ConditionVisitor to handle arbitrary ValueDecls in binary expressions, and also handle inverting the order of comparison when the named decl appears on the RHS.
[libclang] Require explicit cursor visitation for all TypeLocs (compilation will
fail if a TypeLoc kind is not handled) and handle DecltypeTypeLoc and InjectedClassNameTypeLoc.
Ted Kremenek [Mon, 15 Aug 2011 22:10:47 +0000 (22:10 +0000)]
Take 2 (take 3?) at removing derelict clang.xcodeproj. All Xcode users should be using CMake, as the clang.xcodeproj is never up-to-date and cannot actually build Clang.
Bob Wilson [Mon, 15 Aug 2011 19:13:06 +0000 (19:13 +0000)]
Make -findirect-virtual-calls and -fterminated-vtables aliases of -fapple-kext.
Outside the driver, they were already treated that way, but the driver was not
giving them the same special treatment as -fapple-kext, e.g., falling back to
llvm-gcc for i386/Darwin kexts. Radar 9868422.
Douglas Gregor [Mon, 15 Aug 2011 13:59:46 +0000 (13:59 +0000)]
Teach reference initialization from the result of a user-defined
conversion to initialize the standard conversion *after* the
user-defined conversion properly. Fixes PR10644.
Francois Pichet [Sun, 14 Aug 2011 03:52:19 +0000 (03:52 +0000)]
Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization.
Example:
template <class T>
class A {
public:
template <class U> void f(U p) { }
template <> void f(int p) { } // <== class scope specialization
};
This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code.
BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error.
Bob Wilson [Sat, 13 Aug 2011 23:48:55 +0000 (23:48 +0000)]
Reject -mkernel for i386/Darwin C++ code; fall back to llvm-gcc instead.
Since -mkernel implies -fapple-kext, this just extends the current behavior
for -fapple-kext to apply for -mkernel as well. Radar 9933387.
Bob Wilson [Sat, 13 Aug 2011 05:03:46 +0000 (05:03 +0000)]
Move handling of vget_lane/vset_lane before the code that checks the type.
Unlike most of the other Neon intrinsics, these are not overloaded and do not
have the extra argument that specifies the vector type. This has not been
fatal because the lane number operand is supposed to be an ICE and so that
value has harmlessly been used as the type identifier. Radar 9901281.
Ted Kremenek [Fri, 12 Aug 2011 23:37:29 +0000 (23:37 +0000)]
Cleanup various declarations of 'Stmt*' to be 'Stmt *', etc. in libAnalyzer and libStaticAnalyzer[*]. It was highly inconsistent, and very ugly to look at.
Ted Kremenek [Fri, 12 Aug 2011 23:04:46 +0000 (23:04 +0000)]
[analyzer] change "tag" in ProgramPoint from "void*" to a ProgramPointTag*.
Having a notion of an actual ProgramPointTag will aid in introspection of the analyzer's behavior.
For example, the GraphViz output of the analyzer will pretty-print the tags in a useful manner.
Anna Zaks [Fri, 12 Aug 2011 21:56:43 +0000 (21:56 +0000)]
MacOSKeychainAPIChecker:
Report errors earlier: on checkDeadSymbols() and clear the state after the symbol we are tracking goes out of scope.
Also, perform lazy error checking. Instead of forcing the paths to be split depending one the return value of the allocator, make the return symbol depend on the allocated data symbol, which prolongs its life span to the time when the allocated data symbol becomes dead.
Jordy Rose [Fri, 12 Aug 2011 21:41:07 +0000 (21:41 +0000)]
[analyzer] Nitpicks on Olaf's patch, which I meant to e-mail but then didn't in
time. One is cleanup, the other is me being OCD about enum group nesting.
Anna Zaks [Fri, 12 Aug 2011 21:14:26 +0000 (21:14 +0000)]
MacOSKeychainAPIChecker: There is no need to use SymbolMetadata to represent the allocated data symbol, we can just use the symbol corresponding to the SymbolicRegion. This simplifies tracking of the symbol, for example, SymbolMetadata needs to go through extra hoops to stay alive.
Make AllocationState internal to the MacOSKeychainAPIChecker class.
projects / clang / log