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.
llvm-svn: 128898
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.
llvm-svn: 128894
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.
llvm-svn: 128878
1) Change the CFG to include the DeclStmt for conditional variables, instead of using the condition itself as a faux DeclStmt.
2) Update ExprEngine (the static analyzer) to understand (1), so not to regress.
3) Update UninitializedValues.cpp to initialize all tracked variables to Uninitialized at the start of the function/method.
4) Only use the SelfReferenceChecker (SemaDecl.cpp) on global variables, leaving the dataflow analysis to handle other cases.
The combination of (1) and (3) allows the dataflow-based -Wuninitialized to find self-init problems when the initializer
contained control-flow.
llvm-svn: 128858
location into a TemplateSpecializationTypeLoc. These were found using
a hand-written program to inspect every source location in
TemplateSpecializationTypeLocs and Valgrind. I don't know of any way to
test them in Clang's existing test suite sadly.
Example code that triggers the ElaboratedType case:
template <typename T> struct X1 {
template <typename U> struct X1_1 {
int x;
};
};
template <typename T, typename U> struct X2 {
typename X1<T>::template X1_1<U> B;
};
X2<char, int> x2;
The other fix was simply spotted by inspection. I audited all constructions of
[Dependent]TemplateSpecializationTypeLocs in TreeTransform.h, and the rest set
the TemplateNameLoc properly.
llvm-svn: 128702
when the resolution took place due to a single template specialization
being named with an explicit template argument list. In this case, the
"resolution" doesn't take into account the target type at all, and
therefore can take place for functions, static member functions, and
*non-static* member functions. The latter weren't being properly checked
and their proper form enforced in this scenario. We now do so.
The result of this last form slipping through was some confusing logic
in IsStandardConversion handling of these resolved address-of
expressions which eventually exploded in an assert. Simplify this logic
a bit and add some more aggressive asserts to catch improperly formed
expressions getting into this routine.
Finally add systematic testing of member functions, both static and
non-static, in the various forms they can take. One of these is
essentially PR9563, and this commit fixes the crash in that PR. However,
the diagnostics for this are still pretty terrible. We at least are now
accepting the correct constructs and rejecting the invalid ones rather
than accepting invalid or crashing as before.
llvm-svn: 128456
This is basically the same idea as the warning on uninitialized uses of
fields within an initializer list. As such, it is on by default and
under -Wuninitialized.
Original patch by Richard Trieu, with some massaging from me on the
wording and grouping of the diagnostics.
llvm-svn: 128376
platform implies default visibility. To achieve these, refactor our
lookup of explicit visibility so that we search for both an explicit
VisibilityAttr and an appropriate AvailabilityAttr, favoring the
VisibilityAttr if it is present.
llvm-svn: 128336
AttributeLists do not accumulate over the lifetime of parsing, but are
instead reused. Also make the arguments array not require a separate
allocation, and make availability attributes store their stuff in
augmented memory, too.
llvm-svn: 128209
string itself lives longer than the DelayedDiagnostic. Fixes a recent
use-after-free regression due to my availability attribute work.
llvm-svn: 128148
Anders Carlsson