Enhance the diagnostic for literal float -> int conversions to suggest
rewriting the literal when the value is integral. It is not uncommon to
see code written as:
const int kBigNumber = 42e5;
Without any real awareness that this is no longer an ICE. The note helps
automate and ease the process of fixing code that violates the warning.
Oscar Fuentes [Sun, 10 Apr 2011 02:29:27 +0000 (02:29 +0000)]
libclang output name is now libclang. This solves a name collision
when building with Visual Studio. `clang.dll' and `clang.exe' would
have the same `clang.ilk' and `clang.pdb'. On a serial build those
files would be overwritten as clang.exe/clang.dll are created. On a
parallel build there is a risk of both files being written at the same
time. On that case VS fails.
strcat() and strncat() model additions to CStringChecker.
Validates inputs are not NULL, checks for overlapping strings, concatenates the strings checking for buffer overflow, sets the length of the destination string to the sum of the s1 length and the s2 length, binds the return value to the s1 value.
Put the logic for deciding the default name for gcc/g++
in the only place that actually cares about it.
This also pushes an ifdef out of the generic driver code
to a little further down, when the target is actually known.
Hopefully it can be changed into just a runtime check
in the future.
Clean up the bool conversion warning. Group it with other conversion
warnings, and make its text appropriate for constant bool expressions
other than 'false'. This should finish off PR9612.
Add support for warning on general null pointer expressions of boolean
type rather than just the literal 'false'. This begins fixing PR9612,
but the message is now wrong. WIP, the cleanup of the messaging is next.
Start overhauling static analyzer support for C++ constructors. The inlining support isn't complete, and needs
to be reworked to model CallEnter/CallExit (just like all other calls). For now, treat constructors mostly
like other function calls, making the analysis of C++ code just a little more useful.
John Wiegley [Fri, 8 Apr 2011 18:41:53 +0000 (18:41 +0000)]
Use ExprResult& instead of Expr *& in Sema
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
Now that the analyzer is distinguishing between uninitialized uses that
definitely have a path leading to them, and possibly have a path leading
to them; reflect that distinction in the warning text emitted.
Daniel Dunbar [Thu, 7 Apr 2011 18:01:20 +0000 (18:01 +0000)]
Driver: Sketch driver support for a CC_LOG_DIAGNOSTICS options, similar to the
existing CC_PRINT_OPTIONS and CC_PRINT_HEADERS, which can be used to
transparently capture the compiler diagnostics from a build.
John McCall [Thu, 7 Apr 2011 08:22:57 +0000 (08:22 +0000)]
Basic, untested implementation for an "unknown any" type requested by LLDB.
The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use. I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.
John McCall [Wed, 6 Apr 2011 09:02:12 +0000 (09:02 +0000)]
When updating the retain summary based on {cf,ns}_consumed attributes,
be sure to consume the argument index that actually had the attribute
rather than always the first. rdar://problem/9234108
John McCall [Wed, 6 Apr 2011 02:35:25 +0000 (02:35 +0000)]
Diagnose a missing ')' on what looks like a statement expression.
A situation where we can get an invalid ExprResult without an error.
Fixes PR8394. Patch by Justin Bogner!
John McCall [Wed, 6 Apr 2011 01:50:22 +0000 (01:50 +0000)]
Fix getLocForEndOfToken to not double-count spurious internal characters
within a token, like trigraphs and escaped newlines.
Patch by Marcin Kowalczyk!
Commit a bit of a hack to fully handle the situation where variables are
marked explicitly as uninitialized through direct self initialization:
int x = x;
With r128894 we prevented warnings about this code, and this patch
teaches the analysis engine to continue analyzing subsequent uses of
'x'. This should wrap up PR9624.
There is still an open question of whether we should suppress the
maybe-uninitialized warnings resulting from variables initialized in
this fashion. The definitely-uninitialized uses should always be warned.
Add security syntax checker for strcat() which causes the Static Analyzer to generate a warning any time the strcat() function is used with a note suggesting to use a function which provides bounded buffers. CWE-119.
Also, brings the security syntax checker more inline with coding standards.
Andrew Trick [Tue, 5 Apr 2011 18:56:55 +0000 (18:56 +0000)]
Added *hidden* flags -print-options and -print-all-options so
developers can see if their driver changed any cl::Option's. The
current implementation isn't perfect but handles most kinds of
options. This is nice to have when decomposing the stages of
compilation and moving between different drivers. It's also a good
sanity check when comparing results produced by different command line
invocations that are expected to produce the comparable results.
Note: This is not an attempt to prolong the life of cl::Option. On the
contrary, it's a placeholder for a feature that must exist when
cl::Option is replaced by a more appropriate framework. A new
framework needs: a central option registry, dynamic name lookup,
non-global containers of option values (e.g. per-module,
per-function), *and* the ability to print options values and their defaults at
any point during compilation.
Separate the logic for issuing the initialization fixit hint from the
diagnostic emission. The fixit hint, when suggested, typically has
nothing to do with the nature or form of the reference.
Begin refactoring the uninitialized warning code that I uglied up. This
extracts a function to handle the emission of the diagnostic separately
from the walking over the set of uninitialized uses.
Also updates the naming used within this extracted function to be a bit
more consistent with the rest of Clang's naming patterns.
The next step will be breaking this apart so that we can go through
different functions rather than tracking so many boolean variables.
Fix PR9624 by explicitly disabling uninitialized warnings for direct self-init:
int x = x;
GCC disables its warnings on this construct as a way of indicating that
the programmer intentionally wants the variable to be uninitialized.
Only the warning on the initializer is turned off in this iteration.
This makes the code a lot more ugly, but starts commenting the
surprising behavior here. This is a WIP, I want to refactor it
substantially for clarity, and to determine whether subsequent warnings
should be suppressed or not.
Cleanup the style of some of this code prior to functional changes.
I think this moves the code in the desired direction of the new style
recommendations (and style conventional in Clang), but if anyone prefers
the previous style, or has other suggestions just chime in and I'll
follow up.
projects / clang / log