The BlockAddress doesn't have access to the correct basic blocks until the
functions have been cloned. This causes the BlockAddress to point to the old
values. Just wait until the functions have been cloned before copying the
initializers.
PR13163

llvm-svn: 194218

to avoid breaking AST invariants by reusing Stmt nodes within the same
function.

llvm-svn: 194217

Before:
  #define M(NAME) assert(!Context.Verifying &&#NAME);

After:
  #define M(NAME) assert(!Context.Verifying && #NAME);

This fixes llvm.org/PR16156.

llvm-svn: 194216

llvm-svn: 194215

Before:
  [self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
                           aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
                           aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa];
  [self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa,
      aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
      aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa];

After:
  [self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
                        aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
                        aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa];
  [self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
                        aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
                        aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa];

This addresses llvm.org/PR15349 and llvm.org/PR16185.

llvm-svn: 194214

forget to clean up temporaries at the end of it.

llvm-svn: 194213

llvm-svn: 194212

llvm-svn: 194211

Before:
  Constructor()
      : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa(aaaa,
                                                                      aaaa)) {}
After:
  Constructor()
      : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
            aaaaaaaaaaaaaaaaaaaaaaaaa(aaaa, aaaa)) {}

llvm-svn: 194210

As a side-effect, constructors definitions will correctly be recognized
and formatted as function declarations. Tests will be added in a
follow-up patch actually using the correct recognition.

llvm-svn: 194209

If libc++ has not declared bad_array_length, then declare it here just so that it gets into the binary.

llvm-svn: 194208

llvm-svn: 194207

Also - others have complained about some white space issues - sorry about that - continues to be a pain point for me - will try and see what I can do with clang-format this evening after work - as a short term fix, if anyone can email me the files that they have already identified with issues, it would help me speed up a focused fix. sorry.

llvm-svn: 194206

llvm-svn: 194205

Before:
  Constructor::Constructor()
      : some_value{ //
            aaaaaaa //
  } {}

After:
  Constructor::Constructor()
      : some_value{ //
            aaaaaaa //
        } {}

llvm-svn: 194204

llvm-svn: 194203

Minor refinement of VTableBuilder.h: fix wrong indentation, rename a struct field with a more appropriate name

llvm-svn: 194202

of being converted and this path is not relevant to anything at this time
so I have just disabled it for a few days while I'm at the LLVM conference
and don't have time to complete it or properly fix it.

llvm-svn: 194201

llvm-svn: 194200

CMake changes to build the ASan runtime for the iOS simulator. This is a universal library targeting the same architectures as the OSX ASan runtime does, thus the iossim version can't live in the same universal libclang_rt.asan_osx_dynamic.dylib

The difference between the OSX and iossim builds is in the -mios-simulator-version-min and -ios_simulator_version_min flags that tell Clang to compile and link iossim code.

The iossim runtime can only be built on a machine with both Xcode and the iOS Simulator SDK installed. If xcodebuild -version -sdk iphonesimulator Path returns a nonempty path, it is used when compiling and linking the iossim runtime.

llvm-svn: 194199

Ubuntu has published its Saucy release. 'Trusty Tahr' dev has just started. Add its support in Clang

llvm-svn: 194198

llvm-svn: 194197

llvm-svn: 194196

llvm-svn: 194195

llvm-svn: 194194

[Sanitizer] Call Windows unwinder 'slow' and share StackTrace::Unwind across all platforms. No functionality change.

llvm-svn: 194193

llvm-svn: 194192

This hasn't been used for some time.

llvm-svn: 194191

llvm-svn: 194190

llvm-svn: 194189

Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks.

What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing.  

As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable.      

Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas.  What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda.

Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming. 

This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being:
  - generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ...
  - nested variadic expansions such as:
    auto K = [](auto ... OuterArgs) {
      vp([=](auto ... Is) {
          decltype(OuterArgs) OA = OuterArgs;
          return 0;
        }(5)...);
      return 0;
    };
    auto M = K('a', ' ', 1, " -- ", 3.14); 
   currently cause crashes.  I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard.

A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless!

Now let's hope this commit doesn't upset the buildbot gods ;)

Thanks!

llvm-svn: 194188

llvm-svn: 194187

llvm-svn: 194186

More duplicate code removal in <locale>. Hoist common parsing code into two templates: num_get::__do_get_signed and num_get::__do_get_unsigned, and make the do_get routines call them. No functionality change.

llvm-svn: 194185

limited ways) after the next release. See the lengthy discussions (which
are on-going) and the corresponding commit to LLVM's release notes.
Nothing is actually changing at this point, this is just further
spreading the plan.

llvm-svn: 194184

after the 3.4 release to the release notes. See the *lengthy* llvmdev
and cfe-dev threads on this subject. There will be more emails,
discussion and announcements, but I want to make noise in as many places
as I can to get everyone's concerns voiced and understood.

llvm-svn: 194183

It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009. 

It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience.  Using the EvaluateExpressionOptions removes the need for them.

Using that it gets the --debug option from Greg's patch to work cleanly.

It also adds another EvaluateExpressionOption to not trap exceptions when running expressions.  You shouldn't
use this option unless you KNOW your expression can't throw beyond itself.  This is:

<rdar://problem/15374885>

At present this is only available through the SB API's or python.

It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.

llvm-svn: 194182

Summary:
Similar to __FUNCTION__, MSVC exposes the name of the enclosing mangled
function name via __FUNCDNAME__.  This implementation is very naive and
unoptimized, it is expected that __FUNCDNAME__ would be used rarely in
practice.

Reviewers: rnk, rsmith, thakis

CC: cfe-commits, silvas

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

llvm-svn: 194181

This is an addendum to r194174.

llvm-svn: 194180

No functional changes (intended).

llvm-svn: 194179