[cxx-interop] Make sure the size of anonymous types metadata is unchanged

[Xazax-hun]

Add a null pointer to the value witness table instead of completely skipping emitting the pointer.

[Xazax-hun]

@swift-ci please smoke test

[DougGregor]

This will avoid the assertion, thank you. Are we certain that we can't dynamically get to this value witness table? Should we instead stub out the entries in the table?

[Xazax-hun]

Are we certain that we can't dynamically get to this value witness table? Should we instead stub out the entries in the table?

I am not 100% positive yet if there is a way to get to these. Maybe one could with reflection? That being said, I think such code is inherently faulty, the user should only rely on the enclosing non-anonymous type's value witness table.

In case we stub the entries in the table, what would you expect those stubs to do? Trap?

[Xazax-hun]

Merging this for now to fix the size issue and will follow up with a separate PR for the stubs if we decide we should have them.

[rjmccall]

Can we figure out why we're emitting this type metadata in the first place? It's not a nameable type, and I feel like eagerly emitting type metadata for imported field types for reflective purposes is probably a mistake.

[Xazax-hun]

Can we figure out why we're emitting this type metadata in the first place?

The way we currently import anonymous types to Swift we generate a field like __Unnamed_struct___Anonymous_field0 in the enclosing type on the Swift side. Users are not expected to refer to this field ever. We introduce accessors in the enclosing type and users are expected to use those accessors to access the fields of the anonymous structs.

When we generate lazy metadata for the enclosing (non-anonymous type), we will generate field descriptors for all the fields including the field representing the anonymous structure itself. The generation of the field descriptor will trigger the emission of the metadata for this anonymous type.

[Xazax-hun]

eagerly emitting type metadata for imported field types for reflective purposes is probably a mistake.

Are you suggesting that we should not emit type metadata for any field when the parent is imported? I think we might have some facilities that might rely on this behavior. E.g., in Swift we can print a C struct and see the values of all the members.

Or do you mean we should be able to tell when we call something that relies on reflection so we should be more lazy with emitting this metadata?

[rjmccall]

I believe that printing can use several different sources of information. We could also potentially just extend the format of field descriptors to express the things we want to express without having to emit full type metadata records. Type metadata has a lot of overhead specifically related to its use in the runtime type system, so it would be reasonable to put some engineering effort into avoiding that for that types that we have no intention of modeling in Swift.

Also, there are a lot of C/C++ types for which printing their direct recursive structure is not actually useful to users. We're probably spending a lot of time and code size creating type metadata for the implementation details of STL types. We should really only be doing this for aggregates.

[Xazax-hun]

Hmm, it looks like we actually will not generate the reflection related data for private field! So we already avoid generating metadata for some of the implementation details.

I put up a PR to avoid generating reflection metadata for anonymous types too: #84199