Reland of [builtins] DeleteProperty: Handle last-added fast properties

src/compiler/js-native-context-specialization.cc

Index: src/compiler/js-native-context-specialization.cc
diff --git a/src/compiler/js-native-context-specialization.cc b/src/compiler/js-native-context-specialization.cc
index 88d0fba216e0d8f1ab5febcbd98fccec476b534b..661b025d0acc3d822e3ac1a07d6956c9a6c594ea 100644
--- a/src/compiler/js-native-context-specialization.cc
+++ b/src/compiler/js-native-context-specialization.cc
@@ -2310,6 +2310,15 @@ Node* JSNativeContextSpecialization::BuildCheckMaps(
 
 Node* JSNativeContextSpecialization::BuildExtendPropertiesBackingStore(
     Handle<Map> map, Node* properties, Node* effect, Node* control) {
+  // TODO(bmeurer/jkummerow): Property deletions can undo map transitions
+  // while keeping the backing store around, meaning that even though the
+  // map might believe that objects have no unused property fields, there
+  // might actually be some. It would be nice to not create a new backing
+  // store in that case (i.e. when properties->length() >= new_length).
+  // However, introducing branches and Phi nodes here would make it more
+  // difficult for escape analysis to get rid of the backing stores used
+  // for intermediate states of chains of property additions. That makes
+  // it unclear what the best approach is here.
   DCHECK_EQ(0, map->unused_property_fields());
   // Compute the length of the old {properties} and the new properties.
   int length = map->NextFreePropertyIndex() - map->GetInObjectProperties();