Closed-world assumption and GC

[kripken]

The GlobalTypeOptimization pass will remove fields from GC types when they are never used. @askeksa-google noticed that this can break code where JS reads a struct from the outside - the field indexes have changed.

We should probably have an option for this. Should we have a single "closed-world" option perhaps? That could also cover other things like assuming the table is not modified from the outside. Or should we just add a GC-specific option to assume no struct accesses from outside? ("fixed struct ABI")

Alternatively, we could scan the module and see if any GC objects actually escape. But I suspect that will be common, e.g. if the program holds on to JS strings or a canvas context or whatever.

Even more alternatively, if the JS API used names instead of indexes then the initial issue here would have been avoided, but that's probably a larger topic... but cc @jakobkummerow @tlively if there have been recent thoughts there?

[tlively]

I've been assuming we would eventually do the escape analysis to figure out what types we can safely modify, but I agree that lots of types will probably escape. A closed-world option would make sense, especially if we could also either emit some useful mapping (or even just JS?) to help users translate types to their expected ABI or if we could insert fixups ourselves at the module boundary.

[tlively]

We now have a closed-world flag, and new ideas in this are are tracked in #6965.