swift234

Refactor DemanglePrinter to eliminate the possibility of storing a dangling reference.

Before the refactor, a dangling reference to a string may be stored in a DemanglePrinter in at least the following cases:
1) If an lvalue DemanglePrinter is initialized with an rvalue string:
DemanglePrinter printer("abc");
2) If an lvalue DemanglePrinter is initialized with an lvalue string which doesn't live as long as the printer:
unique_ptr<DemanglePrinter> printer;
{
  std::string s = "abc";
  printer = make_unique<DemanglePrinter>(s);
}
// Reference stored in printer is dangling

In addition, in all existing cases in the code where an lvalue DemanglePrinter is used, an empty string is initialized just before it, which isn't DRY, and is related to the previous problem - the coder shouldn't be expected to maintain the lifetime of a string separate from the DemanglePrinter which references it.

In addition, before the refactor, in any in-line use of DemanglePrinter it is constructed with an empty string parameter (in which to construct the string), but this doesn't look very clean.

The refactor solves the above issues by maintaining its own string as a member, while still enabling the original intent of being able to use DemanglePrinter both as an lvalue constructively before getting its value, and in-line as an rvalue.