llvm-svn: 193012

llvm-svn: 193011

llvm-svn: 193010

llvm-svn: 193009

Update to reflect current GC APIs and usage. The example code is taken from the Erlang GC implementation.

llvm-svn: 193008

llvm-svn: 193007

llvm-svn: 193006

test also adds FIXMEs for a number of places where imports and includes of
submodules don't work very well.

llvm-svn: 193005

llvm-svn: 193004

attributes when such methods are actually envoked in message
expression. // rdar://15242010

llvm-svn: 193003

With this commit, all DIEs created in CompileUnit will be added to parents
inside the same function. Also make getOrCreateTemplateType|Value functions
private.

No functionality change.

llvm-svn: 193002

llvm-svn: 193001

This is another (final?) stab at making us able to parse our own asm output
on Windows.

Symbols on Windows often contain @'s and ?'s in their names. Our asm parser
didn't like this. ?'s were not allowed, and @'s were intepreted as trying to
reference PLT/GOT/etc.

We can't just add quotes around the bad names, since e.g. for MinGW, we use gas
to assemble, and it doesn't like quotes in some places (notably in .def
directives).

This commit makes us allow ?'s in symbol names, and @'s in symbol names for MS
assembly.

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

llvm-svn: 193000

llvm-svn: 192999

llvm-svn: 192997

Thanks to Milan Lenčo for noticing it.

llvm-svn: 192996

in the "uknown" state.  Patch by chris.wailes@gmail.com.  Reviewed by delesley.

llvm-svn: 192995

llvm-svn: 192994

Removing Host/Atomic.h
This header file was not being copied as part of our public API headers and this in turn was causing any plugin to link against LLDB.framework, since SharingPtr.h depends on it

Out of several possible options to fix this issue, the cleanest one is to revert LLDB to use std::atomic<>, as we are a C++11 project and should take advantage of it

The original rationale for going from std::atomic to Host/Atomic.h was that MSVC++ fails to link in CLR mode when std::atomic is used
This is a very Visual Studio/.net specific issue, which hopefully will be fixed
Until them, to allow Windows development to proceed, we are going with a targeted solution where we #ifdef include the Windows specific calls, and let everyone else use the
proper atomic support, as should be

If there is an unavoidable need for a LLDB-specific atomic header, the right way to go at it would be to make an API/lldb-atomic.h header and #ifdef the Windows dependency there

The FormatManager should not need to conditionalize use of std::atomic<>, as other parts of the LLDB internals are successfully using atomic (Address and IRExecutionUnit), so this
Win-specific hack is limited to SharingPtr

llvm-svn: 192993

specified.

In particular it makes sure that  relative paths for non-virtual files aren't
made absolute.
Added unittest.

llvm-svn: 192992

default constructor.  Patch by chris.wailes@gmail.com, reviewed by delesley.

llvm-svn: 192991

llvm-svn: 192990

<rdar://problem/15252474>

llvm-svn: 192989

Before, clang-format would not adjust leading indents if it found a
structural error (e.g. unmatched {}). It seems, however, that
clang-format has gotten good enough at parsing the code structure that
this hurts in almost all cases. Commonly, while writing code, it is
very useful to be able to correclty indent incomplete if statements or
for loops.

In case this leads to errors that we don't anticipate, we need to find
out and fix those.

This fixed llvm.org/PR17594.

llvm-svn: 192988

has gone  away by the time they get around to doing it.

<rdar://problem/15245544>

llvm-svn: 192987

Put it back where it belongs.

llvm-svn: 192986

error messages should not be able to occur at the same time.

llvm-svn: 192985

This looks ugly and leads to llvm.org/PR17590.

Before (with AlwaysBreakBeforeMultilineStrings):
  return
      "aaaa"
      "bbbb";

After:
  return "aaaa"
         "bbbb";

llvm-svn: 192984

Specifically, prefer breaking before trailing annotations over breaking
before the first parameter.

Before:
  void ffffffffffffffffffffffff(
      int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
      int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) OVERRIDE;

After:
  void ffffffffffffffffffffffff(int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
                                int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
      OVERRIDE;

llvm-svn: 192983

llvm-svn: 192982

Before:
  aaaaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaa().aaaaaaaaaaaaaaaaa().has<
      bbbbbbbbbbbbbbbbbbbbb>();

After:
  aaaaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaa()
      .aaaaaaaaaaaaaaaaaaaaaaaaaa()
      .has<bbbbbbbbbbbbbbbbbbbbb>();

llvm-svn: 192981

llvm-svn: 192980

llvm-svn: 192979

Forgot to 'svn add'

llvm-svn: 192978

Patch by Artyom Skrobov.

llvm-svn: 192977

PR17168 describes a test case that fails when compiling for debug with
fast-isel.  Investigation showed that the test was failing because a DBG_VALUE
machine instruction was placed prior to a PHI.

For this problem to occur requires the following:
 * Compile for debug
 * Compile with fast-isel
 * In a block B, fast-isel must partially succeed before punting to DAG-isel
 * B must start with a PHI
 * The first unhandled node in the DAG must not generate a machine instruction
 * A debug value with an order less than that of that first node exists

When all of these circumstances apply, the existing test that an instruction
was not inserted won't fire.  Currently it tests whether the block is empty,
or whether the last instruction generated is a phi.  When fast-isel has
partially succeeded, the last instruction generated will not be a phi.
Instead, we need to check whether the current insert position is immediately
following a phi.  This patch adds that check, and adds the test case from the
PR as a regression test.

llvm-svn: 192976

llvm-svn: 192975

Completely harmless, but GCC likes to warn about it even when the next line is
a comment.

llvm-svn: 192974

llvm-svn: 192973

Patch by Artyom Skrobov

llvm-svn: 192972