llvm-svn: 131132

llvm-svn: 131129

Patch by Dan Bailey

llvm-svn: 131128

llvm-svn: 131127

llvm-svn: 131126

one of the sections is created.

llvm-svn: 131124

Patch by Wei-Ren Chen

llvm-svn: 131123

llvm-svn: 131121

llvm-svn: 131120

llvm-svn: 131119

llvm-svn: 131118

llvm-svn: 131117

llvm-svn: 131116

Focus is on default constructors for the time being. Currently the
exception specification and prototype are processed correctly. Codegen
might work but in all likelihood doesn't.

Note that due to an error, out-of-line defaulting of member functions is
currently impossible. It will continue to that until I muster up the
courage to admit that I secretly pray to epimetheus and that I need to
rework the way default gets from Parse -> Sema.

llvm-svn: 131115

reflect our new, more accurate AST.

llvm-svn: 131114

Also some -fdelayed-template-parsing test refactoring.

llvm-svn: 131113

llvm-svn: 131112

llvm-svn: 131111

Make sure writing asynchronous output only backs up
& overwrites prompt if the IOChannel input reader is the top
input reader.

llvm-svn: 131110

unions. Fixes PR8326.

llvm-svn: 131109

llvm-svn: 131108

llvm-svn: 131106

treated as being permanently resident in target
memory.  In fact, since the expression's stack frame
is deleted and potentially re-used after the
expression completes, the variables need to be treated
as being freeze-dried.

llvm-svn: 131104

structs (impacts 32-bit only though).

llvm-svn: 131103

definitions to also include tag declarations. Fixes PR8151.

llvm-svn: 131102

hasTrivialDefaultConstructor() really really means it now.

Also implement a fun standards bug regarding aggregates. Doug, if you'd
like, I can un-implement that bug if you think it is truly a defect.

The bug is that non-special-member constructors are never considered
user-provided, so the following is an aggregate:

struct foo {
  foo(int);
};

It's kind of bad, but the solution isn't obvious - should

struct foo {
  foo (int) = delete;
};

be an aggregate or not?

Lastly, add a missing initialization to FunctionDecl.

llvm-svn: 131101

for http://llvm.org/viewvc/llvm-project?rev=131089&view=rev.

llvm-svn: 131100

also consider whether any of the parameter types (as written, prior to
decay) are dependent. Fixes PR9880 and <rdar://problem/9408413>.

llvm-svn: 131099

before we try to.

Patch by Patrick Walton!

llvm-svn: 131098

llvm-svn: 131097

into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses would need to implement:

virtual bool
ReadRegisterBytes (uint32_t reg, DataExtractor &data);

virtual bool
WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);

There is now a new class specifically designed to hold register values: 
        lldb_private::RegisterValue
        
The new register context calls that subclasses must implement are:

virtual bool
ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0;

virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0;

The RegisterValue class must be big enough to handle any register value. The
class contains an enumeration for the value type, and then a union for the 
data value. Any integer/float values are stored directly in an appropriate
host integer/float. Anything bigger is stored in a byte buffer that has a length
and byte order. The RegisterValue class also knows how to copy register value
bytes into in a buffer with a specified byte order which can be used to write
the register value down into memory, and this does the right thing when not
all bytes from the register values are needed (getting a uint8 from a uint32
register value..). 

All RegiterContext and other sources have been switched over to using the new
regiter value class.

llvm-svn: 131096

llvm-svn: 131094

Patch by Evan Cheng.

llvm-svn: 131093

llvm-svn: 131090

Fix the wrong error message for "platform process info", i.e., with no pid(s) specified for the command.

llvm-svn: 131089

llvm-svn: 131088

modify the semantics slightly to accomodate default constructors (I
hope).

llvm-svn: 131087

Patch by Liu <proljc@gmail.com>!

llvm-svn: 131086

llvm-svn: 131085

when POSIXLY_COMPLIANT is set.
 - Patch by Dave Vasilevsky!

llvm-svn: 131084