This caused PR26870.

llvm-svn: 262935

llvm-svn: 262934

This is one of a series of changes to improve the MSVC visualization of Clang types.
This one focuses on Record and SubstTemplateTypeParmType meaning that, for example,
a TemplateArgumentLoc no longer displays incomprehensibly in the locals window as

  {Argument={DeclArg={Kind=1 QT=0x033acb00 D=0xcccccccc {DeclType=???}}...

but instead much more usefully as

  Type template parameter: SubstTemplateTypeParm: {Identifier (("T"))} => Record, {Identifier (("A"))}

Additional types and improvements will be made in subsequent commits

llvm-svn: 262933

llvm-svn: 262932

llvm-svn: 262931

llvm-svn: 262930

Differential Revision: http://reviews.llvm.org/D17953

llvm-svn: 262929

llvm-svn: 262928

llvm-svn: 262927

llvm-svn: 262926

llvm-svn: 262925

Summary: I left --build-system for backwards compat, in case there are scripts using it. Feel free to ask for its removal too.

Reviewers: chapuni, tstellarAMD

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D17886

llvm-svn: 262924

llvm-svn: 262923

llvm-svn: 262922

Similar to the template cases in r262050, when a C++ method in an
unavailable struct/class calls unavailable API, don't diagnose an error.
I.e., this case was failing:

    void foo() __attribute__((unavailable));
    struct __attribute__((unavailable)) A {
      void bar() { foo(); }
    };

Since A is unavailable, A::bar is allowed to call foo.  However, we were
emitting a diagnostic here.  This commit checks up the context chain
from A::bar, in a manner inspired by SemaDeclAttr.cpp:isDeclUnavailable.

I expected to find other related issues but failed to trigger them:

- I wondered if DeclBase::getAvailability should check for
  `TemplateDecl` instead of `FunctionTemplateDecl`, but I couldn't find
  a way to trigger this.  I left behind a few extra tests to make sure
  we don't regress.

- I wondered if Sema::isFunctionConsideredUnavailable should be
  symmetric, checking up the context chain of the callee (this commit
  only checks up the context chain of the caller).  However, I couldn't
  think of a testcase that didn't require first referencing the
  unavailable type; this, we already diagnose.

rdar://problem/25030656

llvm-svn: 262921

llvm-svn: 262920

llvm-svn: 262919

This commit removes pr25342 for reverting r262670 clearly.

llvm-svn: 262918

llvm-svn: 262917

This reverts commit r262670 due to compile failure.

llvm-svn: 262916

This is a follow-up to r261512, which made the 'strict' availability
attribute flag behave like 'unavailable'.  However, that fix was
insufficient.  The following case would (erroneously) error when the
deployment target was older than 10.9:

    struct __attribute__((availability(macosx,strict,introduced=10.9))) A;
    __attribute__((availability(macosx,strict,introduced=10.9))) void f(A*);

The use of A* in the argument list for f is valid here, since f and A
have the same availability.

The fix is to return AR_Unavailable from DeclBase::getAvailability
instead of AR_NotYetIntroduced.  This also reverts the special handling
added in r261163, instead relying on the well-tested logic for
AR_Unavailable.

rdar://problem/23791325

llvm-svn: 262915

llvm-svn: 262914

llvm-svn: 262913

- move alias help generation to CommandAlias, out of CommandInterpreter
- make alias creation use argument strings instead of OptionArgVectorSP; the former is a more reasonable currency than the latter
- remove m_is_alias from CommandObject, it wasn't actually being used

llvm-svn: 262912

The variables corresponding to command line options are named mechanically.
Because the option for the variable is -noinhibit-exec and not -no-inhibit-exec,
it should be name this way.

llvm-svn: 262911

GNU ld and gold have these paths as default search paths.
If you don't want these directories, pass -nostdlib.

llvm-svn: 262910

Eventually, there will be more things that CommandAlias contains, and I don't want accessors for each of them on the CommandIntepreter
Eventually, we also won't pass around copies of CommandAlias, but that's for a later patch

llvm-svn: 262909

Should fix the breakage in r262902.

llvm-svn: 262908

llvm-svn: 262907

We follow the comments mentioned in http://reviews.llvm.org/D16842#344378 to
implement this new patch.

This patch implements the following vsx instructions:

Vector load/store:
lxv lxvx lxvb16x lxvl lxvll lxvh8x lxvwsx
stxv stxvb16x stxvh8x stxvl stxvll stxvx
Scalar load/store:
lxsd lxssp lxsibzx lxsihzx
stxsd stxssp stxsibx stxsihx
21 instructions

Phabricator: http://reviews.llvm.org/D16919
llvm-svn: 262906

Attempt to fix the Ubuntu buildbot by making FindLongestCommandWord a free template function in lldb_private

llvm-svn: 262905

llvm-svn: 262904

Also note that the operand order changed; the default label is now listed
after the regular labels.

llvm-svn: 262903

This re-applies r262886 with a fix for 32 bit platforms that have 8 byte
pointer alignment, effectively reverting r262892.

Original Message:

  Currently some SDNode operands are malloc'd, some are stored inline in
  subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
  This scheme is complex, inconsistent, and makes refactoring SDNodes
  fairly difficult.

  Instead, we can allocate all of the operands using an ArrayRecycler
  that wraps a BumpPtrAllocator. This keeps the cache locality when
  iterating operands, improves locality when iterating SDNodes without
  looking at operands, and vastly simplifies the ownership semantics.

  It also means we stop overallocating SDNodes by 2-3x and will make it
  simpler to fix the rampant undefined behaviour we have in how we
  mutate SDNodes from one kind to another (See llvm.org/pr26808).

  This is NFC other than the changes in memory behaviour, and I ran some
  LNT tests to make sure this didn't hurt compile time. Not many tests
  changed: there were a couple of 1-2% regressions reported, but there
  were more improvements (of up to 4%) than regressions.

llvm-svn: 262902

Move ProcessAliasOptionsArgs to be a static on CommandAlias; it wasn't using any instance data on the CommandInterpreter anyway

This small step removes one piece of alias machinery from the CommandInterpreter into the CommandAlias

llvm-svn: 262901

Change the way command aliases are stored. Go from a model where a map holds the alias -> underlying command binding and another map holds the alias -> options, to a model where one single map holds the alias -> (all useful data) combination

Right now, obviously, this is just the pair of (CommandObjectSP,OptionArgVectorSP), so NFC

This is step one of a larger - and tricky - refactoring which will turn command aliases into interesting objects instead of passive storage that the command interpreter does smart things to
This refactoring, in turn, will allow us to do interesting things with aliases, such as intelligent and customizable help

llvm-svn: 262900

Thanks to Ahmed Bougacha for noticing!

llvm-svn: 262899

llvm-svn: 262898

llvm-svn: 262897

llvm-svn: 262896