| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
// rdar://9091893
llvm-svn: 129481
|
| |
|
|
|
|
| |
defined in a macro. // rdar://9091893
llvm-svn: 129465
|
| |
|
|
|
|
| |
even if an identifier could resolve to a builtin.
llvm-svn: 129438
|
| |
|
|
| |
llvm-svn: 129426
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the type of one of the base classes then downgrade the missing typename error to a warning. Up to now this is the only case I found where MSVC doesn't require "typename" at class scope. Really strange!
This fixes 1 error when parsing the MSVC 2008 header files.
Example:
template<class T> class A {
public:
typedef int TYPE;
};
template<class T> class B : public A<T> {
public:
A<T>::TYPE a; // no typename required because A<T> is a base class.
};
llvm-svn: 129425
|
| |
|
|
|
|
|
| |
objective-c instead of crashing in IRgen.
// rdar://9154582.
llvm-svn: 129412
|
| |
|
|
|
|
|
|
| |
RTTI is disabled. Similarly, don't suggest throw or try as code
completion results when C++ exceptions are disabled. Fixes
<rdar://problem/9193560>.
llvm-svn: 129346
|
| |
|
|
|
|
| |
Objective-C pointer type. Fixes <rdar://problem/9142559>.
llvm-svn: 129339
|
| |
|
|
|
|
|
|
|
| |
for __unknown_anytype resolution to destructively modify the AST. So that's
what it does now, which significantly simplifies some of the implementation.
Normal member calls work pretty cleanly now, and I added support for
propagating unknown-ness through &.
llvm-svn: 129331
|
| |
|
|
| |
llvm-svn: 129269
|
| |
|
|
| |
llvm-svn: 129265
|
| |
|
|
| |
llvm-svn: 129260
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
represents a dynamic cast where we know that the result is always null.
For example:
struct A {
virtual ~A();
};
struct B final : A { };
struct C { };
bool f(B* b) {
return dynamic_cast<C*>(b);
}
llvm-svn: 129256
|
| |
|
|
|
|
| |
and move a vector-splat check to follow l-value conversion.
llvm-svn: 129254
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 129243
|
| |
|
|
| |
llvm-svn: 129242
|
| |
|
|
|
|
|
|
| |
of template class. The new value is ignored.
This fixes 1 error when parsing MSVC 2010 header files with clang.
llvm-svn: 129240
|
| |
|
|
|
|
| |
for them. The only major missing feature is references.
llvm-svn: 129234
|
| |
|
|
|
|
| |
pageexec@freemail.hu, tweaks by me.
llvm-svn: 129206
|
| |
|
|
|
|
|
| |
warnings, and make its text appropriate for constant bool expressions
other than 'false'. This should finish off PR9612.
llvm-svn: 129205
|
| |
|
|
|
|
|
| |
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.
llvm-svn: 129204
|
| |
|
|
|
|
| |
Patch by Dave Zarzycki!
llvm-svn: 129189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
llvm-svn: 129143
|
| |
|
|
|
|
| |
implicit cast for scalars.
llvm-svn: 129066
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 129065
|
| |
|
|
| |
llvm-svn: 129017
|
| |
|
|
|
|
|
| |
types such that protocols are seached first. Fixes
// rdar://9224670
llvm-svn: 129016
|
| |
|
|
|
|
|
|
| |
function more clear and obvious in behavior.
Add some comments documenting the behavior of the primary diagnostic helper.
llvm-svn: 128901
|
| |
|
|
|
|
|
| |
diagnostic emission. The fixit hint, when suggested, typically has
nothing to do with the nature or form of the reference.
llvm-svn: 128899
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
is a single implementation. No functionality change intended.
llvm-svn: 128877
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
numerous CFG and UninitializedValues analysis changes:
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
|
| |
|
|
|
|
| |
warnings from the dataflow analysis that include within the initializer of a variable.
llvm-svn: 128843
|
| |
|
|
|
|
| |
already has an initializer.
llvm-svn: 128838
|
| |
|
|
|
|
| |
a note with a location for the function prototype.
llvm-svn: 128833
|
| |
|
|
|
|
|
| |
I'm pretty sure this is the right fix, but I would appreciate it if someone
else would double-check.
llvm-svn: 128806
|
| |
|
|
|
|
| |
non-header file.
llvm-svn: 128780
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
of the ASTReader is incomplete, leading to errors like not realizing std::type_info is already defined.
llvm-svn: 128664
|
| |
|
|
|
|
| |
Add a test case for synthesize ivar. // rdar://9070460
llvm-svn: 128554
|
| |
|
|
|
|
| |
assert-less codepath marginally more efficient.
llvm-svn: 128472
|
| |
|
|
|
|
|
|
| |
Microsoft mode.
This fixes a bunch of errors when compiling MSVC header files with the -DDLL flag.
llvm-svn: 128457
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
type-dependent expressions. Fixes rdar://9027658.
llvm-svn: 128437
|
| |
|
|
|
|
|
| |
an executable test to llvm test suite.
// rdar://9070460.
llvm-svn: 128435
|
| |
|
|
| |
llvm-svn: 128427
|
| |
|
|
|
|
| |
// rdar://9181463
llvm-svn: 128410
|
| |
|
|
| |
llvm-svn: 128401
|