Replace TR::Region::create() with registerDestructor()

[jdmpapin]

The object's type is no longer required to be copy-constructible.

[0xdaryl]

Jenkins build all

[0xdaryl]

Seems reasonable to me. @dsouzai , do you have any concerns with this?

[dsouzai]

LGTM. In a future PR, it may be worth adding some debug code (disabled by default) that checks that the assumptions made hold (eg, obj in registerDestructor truly does belong to memory managed by the current TR::Region).

[keithc-ca]

Just like the old code, I think it's unwise to assume the prev link is safe to access after the object has been destroyed: I think that behavior should be restored:

   Destroyer *lastDestroyer = _lastDestroyer;
   while (lastDestroyer != NULL)
      {
      Destroyer *prev = lastDestroyer->prev();
      lastDestroyer->destroy();
      lastDestroyer = prev;
      }

[dsouzai]

lastDestroyer isn't destroyed here; it is a wrapper that contains a pointer to the object to be destroyed.

[keithc-ca]

Even so, this shouldn't assume that the implementation of destroy() didn't, say, clear the prev link.

[dsouzai]

Well, the API contract for destroy in the current impl is to only destroy the containing object, not to reset the current Destroyer's fields. The previous implementation destroyed the containing object (the Destructible object).

[jdmpapin]

Even so, this shouldn't assume that the implementation of destroy() didn't, say, clear the prev link.

Destroyer, TypedDestroyer, and this loop are all just part of the implementation of registerDestructor(). There is no reason for them to evolve independently, and there is therefore no significant API surface between them, and we can know (not assume) precisely what destroy() does. This objection might as well be: this shouldn't assume that the earlier part of the loop body didn't clear the prev link—to which the answer would be that it plainly doesn't.