Commit some changes I had managed to lose last night while refactoring the code. Avoid change use of PHI instructions because it's not legal to insert any instructions before them.
This fixes PR6027.

llvm-svn: 93335

llvm-svn: 93334

llvm-svn: 93333

llvm-svn: 93332

rewriting for any target. (refixes radar 7530235).

llvm-svn: 93331

llvm-svn: 93328

that name constructors, the endless joys of out-of-line constructor
definitions, and various other corner cases that the previous hack
never imagined. Fixes PR5688 and tightens up semantic analysis for
constructor names.

Additionally, fixed a problem where we wouldn't properly enter the
declarator scope of a parenthesized declarator. We were entering the
scope, then leaving it when we saw the ")"; now, we re-enter the
declarator scope before parsing the parameter list.

Note that we are forced to perform some tentative parsing within a
class (call it C) to tell the difference between

  C(int); // constructor

and

  C (f)(int); // member function

which is rather unfortunate. And, although it isn't necessary for
correctness, we use the same tentative-parsing mechanism for
out-of-line constructors to improve diagnostics in icky cases like:

  C::C C::f(int); // error: C::C refers to the constructor name, but
                  // we complain nicely and recover by treating it as
                  // a type.

llvm-svn: 93322

llvm-svn: 93320

to 'make-print-%' to match LLVM.

llvm-svn: 93319

llvm-svn: 93318

twine can be represented as a single StringRef. Use the new methode to simplify
some twine users.

llvm-svn: 93317

information to feed diagnostics instead of regenerating it.  Much room for
improvement here, but fixes some unfortunate problems reporting on method calls.

llvm-svn: 93316

This now rejects literal operators that don't meet the requirements.
Templates are not yet checked for.

llvm-svn: 93315

llvm-svn: 93314

llvm-svn: 93313

disabled with the intent that users can start with them now and not have to change
a thing to have them work when we implement the features.

llvm-svn: 93312

llvm-svn: 93310

llvm-svn: 93309

on linux (even though they are pointless, they shouldn't ICE).

llvm-svn: 93308

llvm-svn: 93307

llvm-svn: 93306

llvm-svn: 93305

llvm-svn: 93304

different BlockAddress labels, but nothing semantically important.

Add a FIXME that BlockAddress codegen is broken if the LLVM BB has 
an empty name (e.g. strip was run).

llvm-svn: 93303

Among other things, this would do very weird things if the 
basic block name had (e.g.) a space in it on darwin:
makeNameProper would add quotes, then the mcsymbol would 
escape the quotes.

llvm-svn: 93302

and use them to avoid a copy of a string in getNameWithPrefix in
the common case.  It seems like Value::setName and other places 
should use this as well?

llvm-svn: 93301

that I want to completely eliminate.  Add fixme's so I remember this
in the future, and add the missing helper that they should be upgraded
to use instead.

llvm-svn: 93300

future work should permit strings (by splitting them into a list o' strings).

llvm-svn: 93299

instead of returning it in an std::string.  Based on this change:

1. Change TargetLoweringObjectFileCOFF::getCOFFSection to take a StringRef
2. Change a bunch of targets to call makeNameProper with a smallstring,
   making several of them *much* more efficient.
3. Rewrite Mangler::makeNameProper to not build names and then prepend
   prefixes, not use temporary std::strings, and to avoid other crimes.

llvm-svn: 93298

llvm-svn: 93297

llvm-svn: 93296

llvm-svn: 93295

llvm-svn: 93294

llvm-svn: 93293

llvm-svn: 93292

integers on 64-bit systems.

llvm-svn: 93291

llvm-svn: 93290

Revert 93270 pending investigation of how stray non-constant values end up in ValueEnumerator's ValueList during WriteConstants()

llvm-svn: 93289

llvm-svn: 93288

llvm-svn: 93287