correspond to the code.

Patch by Stephen McGruer.

llvm-svn: 173914

llvm-svn: 173913

llvm-svn: 173912

llvm-svn: 173911

llvm-svn: 173910

llvm-svn: 173909

llvm-svn: 173908

llvm-svn: 173907

llvm-svn: 173906

an Objective-C method. Fixes <rdar://problem/13069990>.

llvm-svn: 173905

llvm-svn: 173904

can be messaged via the metaclass. Provide code completions for this
case. Fixes <rdar://problem/12560296>.

llvm-svn: 173903

Attempt to fix dragonegg. Use the number of slots to determine if the AttributeSet has attributes or not.

llvm-svn: 173902

                          sext-not-and --> select.

Patch by Muhammad Tauqir Ahmad.

llvm-svn: 173901

llvm-svn: 173900

llvm-svn: 173899

an attribute for consistency with our other noreturn mechanisms.

llvm-svn: 173898

llvm-svn: 173897

llvm-svn: 173896

llvm-svn: 173895

handling that was probably the source of the settings problem.  Need to verify that
it's working correctly tomorrow though.

llvm-svn: 173894

Regenerate configure script for new option to make the buildbots happy.

Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 173893

Enhance lldb so it can search for a kernel in memory when attaching
to a remote system.  Remove some of the code that was doing this
from ProcessMachCore and ProcessGDBRemote and put it in
DynamicLoaderDarwinKernel.

I've added a new setting, plugin.dynamic-loader.darwin-kernel.scan-type
which can be set to

 none   - for environments where reading random memory can cause a
          device crash 
 basic  - look at one fixed location in memory for a kernel load address, 
          plus the contents of that address
 fast-scan - the default, tries "basic" and then looks for the kernel's
          mach header near the current pc value when lldb connects
 exhaustive-scan - on 32-bit targets, step through the entire range where
          the kernel can be loaded, looking for the kernel binary

I don't have the setting set up correctly right now, I'm getting back unexpected
values from the Property system, but I'll figure that out tomorrow and fix.
Besides that, all of the different communication methods / types of kernels 
appear to be working correctly with these changes.

llvm-svn: 173891

This adds a new --with-python option to allow configuration of the python binary
for building.  If not specified, $PATH will be searched for common python binary
names (python, python2, python3).  If specified, and the path is not executable,
it will attempt to search $PATH.

Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Reviewed-by: Eric Christopher &lt;echristo@gmail.com&gt;, Daniel Dunbar <daniel@zuster.org>
llvm-svn: 173890

Summary:
A motivating example:
class ClassWithDtor {
public:
  ~ClassWithDtor() {}
};
void fallthrough3(int n) {
  switch (n) {
    case 2:
      do {
        ClassWithDtor temp;
        return;
      } while (0);  // This generates a chain of unreachable CFG blocks.
    case 3:
      break;
  }
}

Reviewers: rsmith, doug.gregor, alexfh

Reviewed By: alexfh

CC: cfe-commits

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

llvm-svn: 173889

llvm-svn: 173888

llvm-svn: 173887

llvm-svn: 173886

setting of ELF header e_flags.

Contributer: Jack Carter
 
llvm-svn: 173885

setting of ELF header e_flags.

Contributer: Jack Carter
 
llvm-svn: 173884

unresolved using declarations. Fixes PR14768 / <rdar://problem/13030296>.

llvm-svn: 173883

and update ELF header e_flags.

Currently gathering information such as symbol, 
section and data is done by collecting it in an 
MCAssembler object. From MCAssembler and MCAsmLayout 
objects ELFObjectWriter::WriteObject() forms and 
streams out the ELF object file.

This patch just adds a few members to the MCAssember 
class to store and access the e_flag settings. It 
allows for runtime additions to the e_flag by 
assembler directives. The standalone assembler can 
get to MCAssembler from getParser().getStreamer().getAssembler().

This patch is the generic infrastructure and will be
followed by patches for ARM and Mips for their target 
specific use.

Contributer: Jack Carter
 
llvm-svn: 173882

People use the C preprocessor for things other than C files. Some of them
have Unicode characters. We shouldn't warn about Unicode characters
appearing outside of identifiers in this case.

There's not currently a way for the preprocessor to tell if it's in -E mode,
so I added a new flag, derived from the PreprocessorOutputOptions. This is
only used by the Unicode warnings for now, but could conceivably be used by
other warnings or even behavioral differences later.

<rdar://problem/13107323>

llvm-svn: 173881

Suggested in post-commit review by Richard Smith.

llvm-svn: 173880

http://llvm-reviews.chandlerc.com/D332



Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 173879

This simply fixes up quoting of macro invocations to appease newer versions of autotools.

http://llvm-reviews.chandlerc.com/D332



Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 173878

Additional quoting for safety and satisfying newer autotools.  Fix a couple of 80 column violations.

http://llvm-reviews.chandlerc.com/D333



Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 173877

This is needed to allow constant time access to the final layout of atoms.

llvm-svn: 173874

If the member has an initializer, assume it was probably intended to be static
and suggest/recover with that.

If the member doesn't have an initializer, assume it was probably intended to
be const instead of constexpr and suggest that.

(if the attempt to apply these changes fails, don't make any suggestion &
produce the same diagnostic experience as before. The only case where this can
come up that I know of is with a mutable constexpr with an initializer, since
mutable is incompatible with static (but it's already incompatible with
const anyway))

llvm-svn: 173873

argument to be memset, check for its type to be complete 
before calling Context.getTypeSize(PointeeTy) to prevent 
crash. // rdar://13081751.

llvm-svn: 173872