are trivial. This exposes opportunities earlier, and allows fastisel
to do good things with these at -O0.
This addresses rdar://9289468 - clang doesn't fold memset_chk at -O0
llvm-svn: 129651
by making the isCheapEnoughToEvaluateUnconditionally predicate handle anything that folds to a constant. In particular, we now fold enums.
llvm-svn: 129649
To determine what the indentation should be, a SourceLocation 'parentIndent' parameter is used that should be at
a source location with an indentation one degree lower than the given range.
llvm-svn: 129628
Objective-C pointer to void* as a "conversion to void*". This allows
us to prefer an Objective-C object pointer conversion to a superclass
object pointer over an Objective-C object pointer conversion to
cv-void*. Fixes PR9735.
llvm-svn: 129603
address space. I could see that this functionality would be useful,
but not in its current form (where the address space is ignored):
rather, we'd want to encode the address space into the parameter list
passed to operator new/operator delete somehow, which would require a
bunch more semantic analysis.
llvm-svn: 129593
dealing with address-space- and GC-qualified pointers. Previously,
these qualifiers were being treated just like cvr-qualifiers (in some
cases) or were completely ignored, leading to uneven behavior. For
example, const_cast would allow conversion between pointers to
different address spaces.
The new semantics are fairly simple: reinterpret_cast can be used to
explicitly cast between pointers to different address spaces
(including adding/removing addresss spaces), while
static_cast/dynamic_cast/const_cast do not tolerate any changes in the
address space. C-style casts can add/remove/change address spaces
through the reinterpret_cast mechanism. Other non-CVR qualifiers
(e.g., Objective-C GC qualifiers) work similarly.
As part of this change, I tweaked the "casts away constness"
diagnostic to use the term "casts away qualifiers". The term
"constness" actually comes from the C++ standard, despite the fact
that removing "volatile" also falls under that category. In Clang, we
also have restrict, address spaces, ObjC GC attributes, etc., so the
more general "qualifiers" is clearer.
llvm-svn: 129583
is so broken that Sema can't form a declaration for it, don't bother
trying to parse the definition later. Fixes <rdar://problem/9221993>.
llvm-svn: 129547
instantiation), be sure to add the transformed declaration into the
current DeclContext. Also, remove the -Wuninitialized hack that works
around this bug. Fixes <rdar://problem/9200676>.
llvm-svn: 129544
completion, look through block pointer and function pointer types to the
result type of the block/function. Fixes <rdar://problem/9282583>.
llvm-svn: 129535
AAPCS+VFP), similar to fastcall / stdcall / whatevercall seen on x86.
In particular, all library functions should always be AAPCS regardless of floating point ABI used.
llvm-svn: 129534
diagnosing it as an error rather than looping infinitely. Also,
explicitly disallow @defs in Objective-C++. Fixes <rdar://problem/9260136>.
llvm-svn: 129521
named by the nested-name-specifier is same or base of the class in which the member expression appears.
It seems we also had an ill-formed test case, mon dieu! Fixes rdar://8576107.
llvm-svn: 129493
evaluated and unevaluated contexts. Add some testing of sizeof and
typeid.
Both of the typeid tests added here were triggering warnings previously.
Now the one false positive is suppressed without suppressing the warning
on actually buggy code.
llvm-svn: 129431
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
there is no reason to align them higher.
- This roughly matches llvm-gcc's r126913.
- It is an open question whether or not we should do this for cstring's in
general (code size vs optimization potential), for now we just match llvm-gcc
until someone wants to run some experiments.
llvm-svn: 129410
because the result is ignored. The particular example here is with
property l-values, but there could be all sorts of lovely casts that this
isn't safe for. Sink the check into the one case that seems to actually
be capable of honoring this.
llvm-svn: 129397
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
weak linkage. Also, fix a problem where global weak variables
with non-trivial initializers were getting guard variables, or at
least were checking for them and then crashing.
llvm-svn: 129342
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
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
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
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.
llvm-svn: 129215
Make KEYALL a combination of all other flags instead
of its own separate flag. Also rewrite the enum
definitions in hex instead of decimal.
llvm-svn: 129213
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.
llvm-svn: 129212
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
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.
llvm-svn: 129166
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
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
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.
llvm-svn: 128932
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.
llvm-svn: 128911
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
Sandeep Patel noticed that the alignment was wrong for Neon vector types,
and this change is partly derived from his patch. For the APCS ABI, however,
additional changes were required: the maximum ABI alignment is 32 bits and
the preferred alignment for i64 and f64 types should be 64 bits.
llvm-svn: 128825
a couple of operator overloads which form interesting expressions in the
AST.
I added test cases for both bugs with the c-index-test's token
annotation feature. Also, thanks to John McCall for confirming that this
is the correct solution.
llvm-svn: 128768
Chris Lattner