Manuel Klimek [Tue, 31 Jul 2012 13:56:54 +0000 (13:56 +0000)]
Fixes a segfault in Tooling when using pch's:
Clear the FileManager's stat cache in between running
translation units, as the stat cache loaded from a pch
is only valid for one compiler invocation.
John McCall [Tue, 31 Jul 2012 05:14:30 +0000 (05:14 +0000)]
Introduce new queries on ObjCRuntime for how to interpret subscripts
on object pointers and whether pointer arithmetic on object pointers
is supported. Make ObjFW interpret subscripts as pseudo-objects.
Based on a patch by Jonathan Schleifer.
Rafael Espindola [Tue, 31 Jul 2012 02:44:24 +0000 (02:44 +0000)]
Handle functions with struct arguments or return types and the regparm
attribute. It is a variation of the x86_64 ABI:
* A struct returned indirectly uses the first register argument to pass the
pointer.
* Floats, Doubles and structs containing only one of them are not passed in
registers.
* Other structs are split into registers if they fit on the remaining ones.
Otherwise they are passed in memory.
* When a struct doesn't fit it still consumes the registers.
Rafael Espindola [Tue, 31 Jul 2012 01:54:04 +0000 (01:54 +0000)]
Attributes preceding a function declaration are first applied to the return
type and then propagated to the function. This was failing for destructors,
constructors and constructors templates since they don't have a return type.
Fix that by directly calling processTypeAttrs on the dummy type we use as the
return type in these cases.
Jordan Rose [Tue, 31 Jul 2012 01:07:55 +0000 (01:07 +0000)]
[analyzer] Let CallEvent decide what goes in an inital stack frame.
This removes explicit checks for 'this' and 'self' from
Store::enterStackFrame. It also removes getCXXThisRegion() as a virtual
method on all CallEvents; it's now only implemented in the parts of the
hierarchy where it is relevant. Finally, it removes the option to ask
for the ParmVarDecls attached to the definition of an inlined function,
saving a recomputation of the result of getRuntimeDefinition().
Douglas Gregor [Tue, 31 Jul 2012 00:50:07 +0000 (00:50 +0000)]
When we encounter a code-completion token while parsing an ill-formed
lambda-introducer in Objective-C++11, fall back to treating the tokens
as an Objective-C message send to provide those (more likely)
completions. Fixes <rdar://problem/11980263>.
Richard Smith [Mon, 30 Jul 2012 23:48:14 +0000 (23:48 +0000)]
PR13479: If we see the definition of an out-of-line destructor in C++11, be
sure to update the exception specification on the declaration as well as the
definition. If we're building in -fno-exceptions mode, nothing else will
trigger it to be updated.
Jordan Rose [Mon, 30 Jul 2012 23:39:47 +0000 (23:39 +0000)]
[analyzer] Perform post-call checks for all inlined calls.
Previously, we were only checking the origin expressions of inlined calls.
Checkers using the generic postCall and older postObjCMessage callbacks were
ignored. Now that we have CallEventManager, it is much easier to create
a CallEvent generically when exiting an inlined function, which we can then
use for post-call checks.
No test case because we don't (yet) have any checkers that depend on this
behavior (which is why it hadn't been fixed before now).
Richard Smith [Mon, 30 Jul 2012 21:30:52 +0000 (21:30 +0000)]
Improvements to vexing-parse warnings. Make the no-parameters case more
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.
Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.
objective-c arc: ARC IRGen correctly assumes result
type of generated call to super dealloc is 'void'
and asserts if user's dealloc is not of 'void type.
This rule must be enforced in clang front-end (with a
fixit) if this is not the case, instead of asserting in CodeGen.
// rdar://11987838
Anna Zaks [Mon, 30 Jul 2012 20:31:29 +0000 (20:31 +0000)]
[analyzer] Very simple ObjC instance method inlining
- Retrieves the type of the object/receiver from the state.
- Binds self during stack setup.
- Only explores the path on which the method is inlined (no
bifurcation to explore the path on which the method is not inlined).
Jordan Rose [Mon, 30 Jul 2012 20:22:09 +0000 (20:22 +0000)]
[analyzer] Only allow CallEvents to be created by CallEventManager.
This ensures that it is valid to reference-count any CallEvents, and we
won't accidentally try to reclaim a CallEvent that lives on the stack.
It also hides an ugly switch statement for handling CallExprs!
Do not warn on correct use of the '%n' format specifier.
While '%n' can be used for evil in an attacker-controlled format string, there
isn't any acute danger in using it in a literal format string with an argument
of the appropriate type.
Jordan Rose [Mon, 30 Jul 2012 20:21:55 +0000 (20:21 +0000)]
[analyzer] Introduce a CallEventManager to keep a pool of CallEvents.
This allows us to get around the C++ "virtual constructor" problem
when we'd like to create a CallEvent from an ExplodedNode, an inlined
StackFrameContext, or another CallEvent. The solution has three parts:
- CallEventManager uses a BumpPtrAllocator to allocate CallEvent-sized
memory blocks. It also keeps a cache of freed CallEvents for reuse.
- CallEvents all have protected copy constructors, along with cloneTo()
methods that use placement new to copy into CallEventManager-managed
memory, vtables intact.
- CallEvents owned by CallEventManager are now wrapped in an
IntrusiveRefCntPtr. Going forwards, it's probably a good idea to create
ALL CallEvents through the CallEventManager, so that we don't accidentally
try to reclaim a stack-allocated CallEvent.
All of this machinery is currently unused but will be put into use shortly.
Benjamin Kramer [Mon, 30 Jul 2012 15:53:26 +0000 (15:53 +0000)]
Fix ambiguity detection in GetBestOverloadCandidateSimple.
When performing the simplistic overload resolution for single-argument methods,
don't check the best overload for ambiguity with itself when the best overload
doesn't happen to be the first one.
Richard Smith [Sat, 28 Jul 2012 19:54:11 +0000 (19:54 +0000)]
PR13433: In Microsoft mode, don't require function calls within decltype
expressions to have complete return types (or accessible destructors). If the
return type is required to be complete for some other reason (for instance, if
it is needed by overload resolution), then it will still be required to be
complete. This is apparently required in order to parse a MSVC11 header.
objective-c arc: When function calls with known CFCreate naming convention
are cast to retainable types, only suggest CFBridgingRelease/
CFBridgingRetain and not the __bridge casts.
// rdar://11923822
Hans Wennborg [Fri, 27 Jul 2012 19:17:46 +0000 (19:17 +0000)]
Make -Wformat walk the typedef chain when looking for size_t, etc.
Clang's -Wformat fix-its currently suggest using "%zu" for values of
type size_t (in C99 or C++11 mode). However, for a type such as
std::vector<T>::size_type, it does not notice that type is actually
typedeffed to size_t, and instead suggests a format for the underlying
type, such as "%lu" or "%u".
This commit makes the format string fix mechanism walk the typedef chain
so that it notices if the type is size_t, even if that isn't "at the
top".
Anna Zaks [Fri, 27 Jul 2012 19:07:44 +0000 (19:07 +0000)]
Consolidate ObjC lookupPrivateMethod methods from Sema and DeclObjC.
Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.
Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.
Anna Zaks [Fri, 27 Jul 2012 19:07:34 +0000 (19:07 +0000)]
[analyzer] Another false positive in Class method inlining.
We are currently not setting the self object to the calling class object
during inlining nor do we reason about [AAA class].
The __BYTE_ORDER__ predefined macro was added in GCC 4.6:
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/cpp/Common-Predefined-Macros.html
It's used like the following:
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
...
#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
...
#else
#error insane architecture like the pdp-11
#endif
There's a similar macro, __FLOAT_WORD_ORDER__, but it looks like it
mainly exist to accommodate fairly obscure architectures and ARM's
old FPA instructions, so it doesn't seem nearly as useful.
The tests are updated to check for the correct(at least, based on
clang's current output) value of the macro on each target. So now the
suite will catch bugs like the one fixed in r157626.
Richard Smith [Fri, 27 Jul 2012 04:22:15 +0000 (04:22 +0000)]
Final piece of core issue 1330: delay computing the exception specification of
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
Jordan Rose [Fri, 27 Jul 2012 01:15:02 +0000 (01:15 +0000)]
[analyzer] Look through SubstNonTypeTemplateParmExprs.
We were treating this like a CXXDefaultArgExpr, but
SubstNonTypeTemplateParmExpr actually appears when a template is
instantiated, i.e. we have all the information necessary to evaluate it.
This allows us to inline functions like llvm::array_lengthof.
Jordan Rose [Fri, 27 Jul 2012 00:47:52 +0000 (00:47 +0000)]
[analyzer] Use a stack-based local AGAIN to fix the build for real.
It's a good thing CallEvents aren't created all over the place yet.
I checked all the uses this time and the private copy constructor
/really/ shouldn't cause any more problems.
objc-arc: When objects with known CF semantics are assigned to
retainable types in arc, only suggest CFBridgingRelease/
CFBridgingRetain and not the confusing __bridge casts.
// rdar://11923822
Look at the preceding CFGBlock for the expression to load from in ExprEngine::VisitGuardedExpr
instead of walking to the preceding PostStmt node. There are cases where the last evaluated
expression does not appear in the ExplodedGraph.
Jordan Rose [Thu, 26 Jul 2012 21:41:15 +0000 (21:41 +0000)]
[analyzer] CallEvent is no longer a value object.
After discussion, the type-based dispatch was decided to be bad for
maintenance and made it very easy for subtle bugs to creep in. Instead,
we'll just be very careful when we do have to allocate these on the heap.
Jordan Rose [Thu, 26 Jul 2012 20:04:30 +0000 (20:04 +0000)]
[analyzer] Don't crash on implicit statements inside initializers.
Our BugReporter knows how to deal with implicit statements: it looks in
the ParentMap until it finds a parent with a valid location. However, since
initializers are not in the body of a constructor, their sub-expressions are
not in the ParentMap. That was easy enough to fix in AnalysisDeclContext.
...and then even once THAT was fixed, there's still an extra funny case
of Objective-C object pointer fields under ARC, which are initialized with
a top-level ImplicitValueInitExpr. To catch these cases,
PathDiagnosticLocation will now fall back to the start of the current
function if it can't find any other valid SourceLocations. This isn't great,
but it's miles better than a crash.
(All of this is only relevant when constructors and destructors are being
inlined, i.e. under -cfg-add-initializers and -cfg-add-implicit-dtors.)
Jordan Rose [Thu, 26 Jul 2012 20:04:25 +0000 (20:04 +0000)]
[analyzer] Don't crash on array constructors and destructors.
This workaround is fairly lame: we simulate the first element's constructor
and destructor and rely on the region invalidation to "initialize" the rest
of the elements.
Jordan Rose [Thu, 26 Jul 2012 20:04:13 +0000 (20:04 +0000)]
[analyzer] Handle base class initializers and destructors.
Most of the logic here is fairly simple; the interesting thing is that
we now distinguish complete constructors from base or delegate constructors.
We also make sure to cast to the base class before evaluating a constructor
or destructor, since non-virtual base classes may behave differently.
This includes some refactoring of VisitCXXConstructExpr and VisitCXXDestructor
in order to keep ExprEngine.cpp as clean as possible (leaving the details for
ExprEngineCXX.cpp).
Jordan Rose [Thu, 26 Jul 2012 20:04:05 +0000 (20:04 +0000)]
[analyzer] Show paths for destructor calls.
This modifies BugReporter and friends to handle CallEnter and CallExitEnd
program points that came from implicit call CFG nodes (read: destructors).
This required some extra handling for nested implicit calls. For example,
the added multiple-inheritance test case has a call graph that looks like this:
In this case we correctly notice that we started in an inlined function
when we reach the CallEnter program point for the second ~SmartPointer.
However, when we reach the next CallEnter (for ~Subclass), we were
accidentally re-using the inner ~SmartPointer call in the diagnostics.
Rather than guess if we saw the corresponding CallExitEnd based on the
contents of the active path, we now just ask the PathDiagnostic if there's
any known stack before popping off the top path.
(A similar issue could have occured without multiple inheritance, but there
wasn't a test case for it.)
projects / clang / log