Bug 1555990 - fix theoretical xptcodegen issue with nested array types; r=nika

When we're lowering extra types (e.g. array element types) and we find
that we haven't already lowered the type, we say that the new type is
going to live at the end of the `types` array.  But we don't append a
new type (i.e. filling in the entry) until after we call `lower_type`,
which means that some other call to `lower_extra_type` might find
that *its* new type will live at the same position we "allocated" higher
up on the stack.

We don't appear to run into this issue, as the only nested array types
are things like `Array<Array<uint8>>`, and `uint8` is guaranteed to
already have been lowered.  But if people start doing more complicated
things, we're bound to run into this sooner or later.

Differential Revision: https://phabricator.services.mozilla.com/D33299

--HG--
extra : moz-landing-system : lando

xpcom/reflect/xptinfo/xptcodegen.py

@@ -252,7 +252,11 @@ def link_to_cpp(interfaces, fd):
         idx = type_cache.get(key)
         if idx is None:
             idx = type_cache[key] = len(types)
-            types.append(lower_type(type))
+            # Make sure `types` is the proper length for any recursive calls
+            # to `lower_extra_type` that might happen from within `lower_type`.
+            types.append(None)
+            realtype = lower_type(type)
+            types[idx] = realtype
         return idx
 
     def describe_type(type):  # Create the type's documentation comment.