For property iterators it is necessary for shapes in dictionary mode that have holes to settle over the holes in this case. We currently do not "settle" is the constructor. In the testcase provided, It is causing an issue when we generate CacheIR for a stub with a dictionary shape and then delete a property from the shape. We later try to get the deleted property from the dictionary to spew for generating a cacheIRHealthReport, but it has been deleted. Calling settle in the constructor should resolve this problem.

Ensuring dictionary maps don't have 'trailing' holes was a performance optimization. ShapePropertyIter is perf sensitive and I don't think we should add this extra overhead to its constructor.

More importantly: for stale dictionary shapes, the map + mapLength information is stale too, we can't trust the property information anymore because map deletions/compactions could have changed the map completely underneath us so we could be dumping property names that don't correspond to the dictionary shape anymore.

It might be simplest to ignore dictionary shapes in the spewing code for now.