Stopping at '@' was originally intended to avoid skipping an '@' at the @interface context
when doing parser recovery, but we should not stop at all '@' tokens because they may be part
of expressions (e.g. in @"string", @selector(), etc.), so in most cases we will want to skip them.
This commit caused 'test/Parser/method-def-in-class.m' to fail for the cases where we tried to
recover from unmatched angle bracket but IMO it is not a big deal to not have good recovery
from such broken code and the way we did recovery would not always work anyway (e.g. if there was '@'
in an expression).
The case that rdar://7029784 is about still passes.
llvm-svn: 146815
because the memory associated with them is going to get released.
We also don't want them to affect later parsing.
(We do the same for C++ inline methods.)
The underlying cause for the leftover tokens is going to be addressed in the
next commit.
Couldn't get a test case for the crash though. rdar://10583033.
llvm-svn: 146814
as part of the thread format output.
Currently this is only done for the ThreadPlanStepOut.
Add a convenience API ABI::GetReturnValueObject.
Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than
trying to hand out one of its subsidiary object's pointers. That way this will always
be good.
llvm-svn: 146806
enhanced disassembler classify disassemblers by
target triple (as a string) rather than just by
the architecture component of the triple. This
fixes a problem where different variants of the
Thumb instruction set were lumped into the same
hash bucket.
llvm-svn: 146799
Check if the input parameters are tainted (or point to tainted data) on
a checkPreStmt<CallExpr>. If the output should be tainted, record it in
the state. On post visit (checkPostStmt<CallExpr>), use the state to
make decisions (in addition to the existing logic). Use this logic for
atoi and fscanf.
llvm-svn: 146793
declaration for the type then go ahead and use that, it's still smaller
than creating an all new derived type.
Part of rdar://10335756 and others.
llvm-svn: 146779
valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider
Patch from Enrico Granata:
The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem.
The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own.
Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly.
llvm-svn: 146768
#__include_macros) in the arguments of a function-style macro. Directives in the
arguments of such macros have undefined behaviour, and GCC does not correctly
support these cases. In some situations, this can lead to better diagnostics.
llvm-svn: 146765
This is equal to alignof(std::max_align_t) on the platform and equal to the
alignment provided by malloc. (Platform owners please double-check your
platform's value.)
llvm-svn: 146762
we handle Objective-C method calls. Currently,
LLDB treats the result of an Objective-C method
as unknown if the type information doesn't have
the method's signature. Now Clang can cast the
result to id if it isn't explicitly cast.
I also added a test case for this, as well as a
fix for a type import problem that this feature
exposed.
llvm-svn: 146756
Argyrios Kyrtzidis