Additionally, all such cases are handled with no dynamic check.

All `classof()` of the form

    class Foo {
      [...]
      static bool classof(const Bar *) { return true; }
      [...]
    }

where Foo is an ancestor of Bar are no longer necessary.
Don't write them!

Note: The exact test is `is_base_of<Foo, Bar>`, which is non-strict, so
that Foo is considered an ancestor of itself.

This leads to the following rule of thumb for LLVM-style RTTI:

    The argument type of `classof()` should be a strict ancestor.

For more information about implementing LLVM-style RTTI, see
docs/HowToSetUpLLVMStyleRTTI.rst

llvm-svn: 165765

This classof() is effectively saying that a MachineCodeEmitter "is-a"
JITEmitter, but JITEmitter is in fact a descendant of
MachineCodeEmitter, so this is not semantically correct. Consequently,
none of the assertions that rely on these classof() actualy check
anything.

Remove the RTTI (which didn't actually check anything) and use
static_cast<> instead.

Post-Mortem Bug Analysis
========================

Cause of the bug
----------------

r55022 appears to be the source of the classof() and assertions removed
by this commit. It aimed at removing some dynamic_cast<> that were
solely in the assertions. A typical diff hunk from that commit looked
like:

  -  assert(dynamic_cast<JITEmitter*>(MCE) && "Unexpected MCE?");
  -  JITEmitter *JE = static_cast<JITEmitter*>(getCodeEmitter());
  +  assert(isa<JITEmitter>(MCE) && "Unexpected MCE?");
  +  JITEmitter *JE = cast<JITEmitter>(getCodeEmitter());

Hence, the source of the bug then seems to be an attempt to replace
dynamic_cast<> with LLVM-style RTTI without properly setting up the
class hierarchy for LLVM-style RTTI. The bug therefore appears to be
simply a "thinko".

What initially indicated the presence of the bug
------------------------------------------------

After implementing automatic upcasting for isa<>, classof() functions of
the form

  static bool classof(const Foo *) { return true; }

were removed, since they only serve the purpose of optimizing
statically-OK upcasts. A subsequent recompilation triggered a build
failure on the isa<> tests within the removed asserts, since the
automatic upcasting (correctly) failed to substitute this classof().

Key to pinning down the root cause of the bug
---------------------------------------------

After being alerted to the presence of the bug, some thought about the
semantics which were being asserted by the buggy classof() revealed that
it was incorrect.

How the bug could have been prevented
-------------------------------------

This bug could have been prevented by better documentation for how to
set up LLVM-style RTTI. This should be solved by the recently added
documentation HowToSetUpLLVMStyleRTTI. However, this bug suggests that
the documentation should clearly explain the contract that classof()
must fulfill. The HowToSetUpLLVMStyleRTTI already explains this
contract, but it is a little tucked away. A future patch will expand
that explanation and make it more prominent.

There does not appear to be a simple way to have the compiler prevent
this bug, since fundamentally it boiled down to a spurious classof()
where the programmer made an erroneous statement about the conversion.
This suggests that perhaps the interface to LLVM-style RTTI of classof()
is not the best. There is already some evidence for this, since in a
number of places Clang has classof() forward to classofKind(Kind K)
which evaluates the cast in terms of just the Kind. This could probably
be generalized to simply a `static const Kind MyKind;` field in leaf
classes and `static const Kind firstMyKind, lastMyKind;` for non-leaf
classes, and have the rest of the work be done inside Casting.h,
assuming that the Kind enum is laid out in a preorder traversal of the
inheritance tree.

llvm-svn: 165764

This only applies if the type has a name. (we could potentially do something
crazy with decltype in C++11 to qualify members of unnamed types but that
seems excessive)

It might be nice to also suggest a fixit for "&this->i", "&foo->i",
and "&foo.i" but those expressions produce 'bound' member functions that have
a different AST representation & make error recovery a little trickier. Left
as future work.

llvm-svn: 165763

llvm-svn: 165762

llvm-svn: 165761

llvm-svn: 165760

When all cases of a switch statement are dead, the weights vector only has one
element, and we will get an ssertion failure when calling createBranchWeights.

llvm-svn: 165759

llvm-svn: 165758

llvm-svn: 165757

Fixed an issue where we would try to launch an application twice and the second failure would cover up the first.

llvm-svn: 165756

llvm-svn: 165755

change in the LLDB target data API.

llvm-svn: 165754

llvm-svn: 165753

reimplemented in the AsmParser where it belongs.

llvm-svn: 165752

now unused static helper function.

The test case needs to be remove temporarily until I can better filter memory
operands that aren't actual variable reference.

llvm-svn: 165751

llvm-svn: 165747

only with modules, when two disjoint modules #define the same
identifier to different token sequences.

llvm-svn: 165746

llvm-svn: 165744

objc_atomicCompareAndSwap.

llvm-svn: 165743

llvm-svn: 165742

llvm-svn: 165741

Fixed an indentation issue that only shows up when dumping .o files that use linked addresses (DWARF in .o files with debug map).

llvm-svn: 165740

to the instruction position.  The old encoding would give an absolute
ID which counts up within a function, and only resets at the next function.

I.e., Instead of having:

... = icmp eq i32 n-1, n-2
br i1 ..., label %bb1, label %bb2

it will now be roughly:

... = icmp eq i32 1, 2
br i1 1, label %bb1, label %bb2

This makes it so that ids remain relatively small and can be encoded
in fewer bits.

With this encoding, forward reference operands will be given
negative-valued IDs.  Use signed VBRs for the most common case
of forward references, which is phi instructions.

To retain backward compatibility we bump the bitcode version
from 0 to 1 to distinguish between the different encodings.

llvm-svn: 165739

llvm-svn: 165736

in c-index-test. index_enteredMainFile is not invoked when indexing a
module file.

llvm-svn: 165735

llvm-svn: 165734

llvm-svn: 165733

llvm-svn: 165732

llvm-svn: 165731

Dynamic type code must be efficient and fast. Now it is.

Added ObjC v1 support for getting the complete list of ISA values.

The main flow of the AppleObjCRuntime subclasses is now they must override "virtual bool UpdateISAToDescriptorMap_Impl();". This function will update the complete list of ISA values and create ClassDescriptorSP objects for each one. Now we have the complete list of valid ISA values which we can use for verification when doing dynamic typing.

Refactored a bunch of stuff so that the AppleObjCRuntime subclasses don't have to implement as many functions as they used to.

llvm-svn: 165730

associated with deserializing macro history for an identifier.

llvm-svn: 165729

llvm-svn: 165728

llvm-svn: 165727

Add in the first iteration of support for llvm/clang/lldb to allow variable per address space pointer sizes to be optimized correctly.

llvm-svn: 165726

Fix-up for r165718, should get the buildbots back online.

llvm-svn: 165723

with x86/ARM architecture

llvm-svn: 165722

Not all instructions define a virtual register in their first operand.
Specifically, INLINEASM has a different format.

<rdar://problem/12472811>

llvm-svn: 165721

Grosser.

llvm-svn: 165720

This is a "safe" pattern, or at least one that cannot be helped by using
a strong local variable. However, if the single read is within a loop,
it should /always/ be treated as potentially dangerous.

<rdar://problem/12437490>

llvm-svn: 165719

Previously, [foo weakProp] was not being treated the same as foo.weakProp.
Now, for every explicit message send, we check if it's a property access,
and if so, if the property is weak. Then for every assignment of a
message, we have to do the same thing again.

This is a potentially expensive increase because determining whether a
method is a property accessor requires searching through the methods it
overrides. However, without it -Warc-repeated-use-of-weak will miss cases
from people who prefer not to use dot syntax. If this turns out to be
too expensive, we can try caching the result somewhere, or even lose
precision by not checking superclass methods. The warning is off-by-default,
though.

<rdar://problem/12407765>

llvm-svn: 165718