PR20038: DebugInfo: Call sites without DebugLocs for temporary dtors after a conditional

With && at the top level of an expression, the last thing done when
emitting the expression was an unconditional jump to the cleanup block.
To reduce the amount of stepping, the DebugLoc is omitted from the
unconditional jump. This is done by clearing the IRBuilder's
"CurrentDebugLocation"*. If this is not set to some non-empty value
before the cleanup block is emitted, the cleanups don't get a location
either. If a call without a location is emitted in a function with debug
info, and that call is then inlined - bad things happen. (without a
location for the call site, the inliner would just leave the inlined
DebugLocs as they were - pointing to roots in the original function, not
inlined into the current function)

Follow up commit to LLVM will ensure that breaking the invariants of the
DebugLoc chains by having chains that don't lead to the current function
will fail assertions, so we shouldn't accidentally slip any of these
cases in anymore. Those assertions may reveal further cases that need to
be fixed in clang, though I've tried to test heavily to avoid that.

* See r128471, r128513 for the code that clears the
  CurrentDebugLocation. Simply removing this code or moving the code
  into IRBuilder to apply to all unconditional branches would regress
  desired behavior, unfortunately.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@211722 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Propagate class-level DLL attributes to class template specialization bases (PR11170)

Consider the following code:

  template <typename T> class Base {};
  class __declspec(dllexport) class Derived : public Base<int> {}

When the base of an exported or imported class is a class template
specialization, MSVC will propagate the dll attribute to the base.
In the example code, Base<int> becomes a dllexported class.

This commit makes Clang do the proopagation when the base hasn't been
instantiated yet, and warns about it being unsupported otherwise.
This is different from MSVC, which allows changing a specialization
back and forth between dllimport and dllexport and seems to let the
last one win. Changing the dll attribute after instantiation would be
hard for us, and doesn't seem to come up in practice, so I think this
is a reasonable limitation to have.

MinGW doesn't do this kind of propagation.

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

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@211725 91177308-0d34-0410-b5e6-96231b3b80d8