llvm-svn: 181005

MSVC provides __wchar_t, either as an alias for the built-in wchar_t
type, or as a separate type depending on language (C vs C++) and flags
(-fno-wchar).

In -fms-extensions, Clang will simply accept __wchar_t as an alias for
whatever type is used for wide character literals. In -fms-compatibility, we
try to mimic MSVC's behavior by always making __wchar_t a builtin type.

This fixes PR15815.

llvm-svn: 181004

llvm-svn: 181001

a lambda.

Bug #1 is that CGF's CurFuncDecl was "stuck" at lambda invocation
functions.  Fix that by generally improving getNonClosureContext
to look through lambdas and captured statements but only report
code contexts, which is generally what's wanted.  Audit uses of
CurFuncDecl and getNonClosureAncestor for correctness.

Bug #2 is that lambdas weren't specially mapping 'self' when inside
an ObjC method.  Fix that by removing the requirement for that
and using the normal EmitDeclRefLValue path in LoadObjCSelf.

rdar://13800041

llvm-svn: 181000

FindLastStoreBRVisitor is responsible for finding where a particular region
gets its value; if the region is a VarRegion, it's possible that value was
assigned at initialization, i.e. at its DeclStmt. However, if a function is
called recursively, the same DeclStmt may be evaluated multiple times in
multiple stack frames. FindLastStoreBRVisitor was not taking this into
account and just picking the first one it saw.

<rdar://problem/13787723>

llvm-svn: 180997

There were actually two bugs here:
- if we decided to look for an interesting lvalue or call expression, we
  wouldn't go find its node if we also knew we were at a (different) call.
- if we looked through one message send with a  nil receiver, we thought we
  were still looking at an argument to the original call.

Put together, this kept us from being able to track the right values, which
means sub-par diagnostics and worse false-positive suppression.

Noticed by inspection.

llvm-svn: 180996

thread before UnwindLLDB::AddOneMoreFrame calls it quits.  We have
a couple of reports of unending backtraces in the field and we
haven't been able to collect any information about what kind of
backtrace is causing this.  We've found on Mac OS X that it's tricky
to get more than around 200k stack frames before a process exceeds
its stack space so we're starting with a hard limit of 300,000 frames.
<rdar://problem/13383069> 

llvm-svn: 180995

llvm-svn: 180994

llvm-svn: 180993

llvm-svn: 180992

llvm-svn: 180991

This reverts commit 180982.

llvm-svn: 180990

match when looking at kext on the local filesystem.
<rdar://problem/13785112> 

llvm-svn: 180989

llvm-svn: 180988

SWIG is smart enough to recognize that C++ operators == and != mean __eq__ and __ne__ in Python and do the appropriate translation
But it is not smart enough to recognize that mySBObject == None should return False instead of erroring out
The %pythoncode blocks are meant to provide those extra smarts (and they play some SWIG&Python magic to find the right function to call behind the scenes with no risk of typos :-)
Lastly, SBBreakpoint provides an == but never provided a != operator - common courtesy is to provide both

llvm-svn: 180987

llvm-svn: 180986

Without any conversion, this is pretty straightforward.  Most of the
fields can be zeros.  The order is:

- field offset or pointer
- nonvirtual adjustment (for MI functions)
- vbptr offset (for unspecified)
- virtual adjustment offset (for virtual inheritance)

Differential Revision: http://llvm-reviews.chandlerc.com/D699

llvm-svn: 180985

Make sure to handle all thumb variants correctly.

llvm-svn: 180984

llvm-svn: 180983

- Use the debug location of the return expression for the cleanup code
  if the return expression is trivially evaluatable, regardless of the
  number of stop points in the function.
- Ensure that any EH code in the cleanup still gets the line number of
  the closing } of the lexical scope.
- Added a testcase with EH in the cleanup.

rdar://problem/13442648

llvm-svn: 180982

of a weird merge error with git.

llvm-svn: 180981

Use unbuffered I/O. This reduces the runtime by about half. Our implementation is now only about 5 times slower than gcc's.

llvm-svn: 180980

This reverts commit 180974. It broke the build.

llvm-svn: 180979

the "identifier" parsed by the frontend callback by skipping forward
until we've consumed a token that ends at the point dictated by the
callback.

In addition, inform the callback when it's parsing an unevaluated
operand (e.g. mov eax, LENGTH A::x) as opposed to an evaluated one
(e.g. mov eax, [A::x]).

This commit depends on a clang commit.

llvm-svn: 180978

llvm-svn: 180977

the actual parser and support arbitrary id-expressions.

We're actually basically set up to do arbitrary expressions here
if we wanted to.

Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat.  The logic here under template instantiation
is incorrect;  we need to preserve the fact that an expression was
unevaluated.  Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser.  It's all just fishy.

I've also fixed the serialization of MS asm statements.

This commit depends on an LLVM commit.

llvm-svn: 180976

Allow command script import to load packages.

e.g.:
egranata$ ./lldb
(lldb) command script import lldb.macosx.crashlog
"crashlog" and "save_crashlog" command installed, use the "--help" option for detailed help
"malloc_info", "ptr_refs", "cstr_refs", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help.
The "unwind-diagnose" command has been installed, type "help unwind-diagnose" for detailed help.
(lldb) 

./lldb
(lldb) command script import theFoo
I am happy
(lldb) fbc
àèìòù
(lldb)

egranata$ ls theFoo/
__init__.py theBar.py

egranata$ cat theFoo/__init__.py 
import lldb
import theBar

def __lldb_init_module(debugger, internal_dict):
	print "I am happy"
	debugger.HandleCommand("command script add -f theFoo.theBar.theCommand fbc")
	return None

egranata$ cat theFoo/theBar.py 
#encoding=utf-8

def theCommand(debugger, command, result, internal_dict):
	result.PutCString(u"àèìòù")
	return None

llvm-svn: 180975

BugReporter is used to process ALL bug reports.  By using a shared map,
we are having mappings from different PathDiagnosticPieces to LocationContexts
well beyond the point where we are processing a given report.  This
state is inherently error prone, and is analogous to using a global
variable.  Instead, just create a temporary map, one per report,
and when we are done with it we throw it away.  No extra state.

llvm-svn: 180974

This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align((Align)))) char storage[Size];
 };

while this would parse as a "parameter name" 'Align':

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align(Align))) char storage[Size];
 };

The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align)) char storage[Size];
 };

i.e., use the maximal alignment rather than the specified alignment.

Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.

Fixes <rdar://problem/13700933>.

llvm-svn: 180973

llvm-svn: 180972

If HandleCommands is called with add_to_history set to false, turn on the m_command_source_depth so that when we forget the value for regex & alias commands it still stays off.

<rdar://problem/13795202>

llvm-svn: 180971

This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":

  template<unsigned Size, unsigned Align>
  class my_aligned_storage
  {
    __attribute__((align((Align)))) char storage[Size];
  };

while this would parse as a "parameter name" 'Align':

  template<unsigned Size, unsigned Align>
  class my_aligned_storage
  {
    __attribute__((align(Align))) char storage[Size];
  };

The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to

  template<unsigned Size, unsigned Align>
  class my_aligned_storage
  {
    __attribute__((align)) char storage[Size];
  };

i.e., use the maximal alignment rather than the specified alignment.

Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.

Fixes <rdar://problem/13700933>.

llvm-svn: 180970

register.

- Define pseudo instructions which store or load ccond field of the DSP
  control register.
- Emit the pseudos in MipsSEInstrInfo::storeRegToStack and loadRegFromStack.
- Expand the pseudos before callee-scan save.
- Emit instructions RDDSP or WRDSP to copy between ccond field and GPRs. 

llvm-svn: 180969

llvm-svn: 180968

llvm-svn: 180967

Updated the logic for the Sketch test case

llvm-svn: 180966

Mark TestConstVariables as expected to fail due to radar 13314878 on darwin. The tests are already skipped on linux.

llvm-svn: 180965

llvm-svn: 180964

TestPlatformCommand failing on buildbot.

llvm-svn: 180963

DynamicLoaderDarwinKernel finds in memory, have DynamicLoaderDarwinKernel
re-set the Target's arch based on the kernel's cpu type / cpu subtype.

llvm-svn: 180962