On 5/21/25 10:15 PM, Nathaniel Shead wrote:
Another approach would be to fix 'write_class_def' to handle these
declarations better, but that ended up being more work and felt fragile.
It also meant streaming a lot more information that we don't need.
Long term I had been playing around with reworking ubsan.cc entirely to
have a fixed set of types it would use we that we could merge with, but
given that there seems to be at least one other place we are creating
ad-hoc types (the struct for constexpr new allocations), and I couldn't
see an easy way of reworking that, I thought we should support this.
Finally, I'm not 100% certain about the hard-coding MK_unique for fields
of contextless types, but given that we've given up merging the owning
TYPE_DECL with anything anyway I think it should be OK.
-- >8 --
Currently, most declarations must have a DECL_CONTEXT for modules
streaming to behave correctly, so that they can have an appropriate
merge key generated and be correctly deduplicated on import.
There are a few exceptions, however, for internally generated
declarations that will never be merged and don't necessarily have an
appropriate parent to key off for the context. One case that's come up
a few times is TYPE_DECLs, especially temporary RECORD_TYPEs used as
intermediaries within expressions.
Previously I've tried to give all such types a DECL_CONTEXT, but in some
cases that has ended up being infeasible, such as with the types
generated by UBSan (which are shared with the C frontend and don't know
their context, especially when created at global scope). Additionally,
these types often don't have many of the parts that a normal struct
declaration created via parsing user code would have, which confuses
module streaming.
Given that these types are typically intended to be one-off and unique
anyway, this patch instead adds support for by-value streaming of
uncontexted TYPE_DECLs. The patch only support streaming the bare
minimum amount of fields needed for the cases I've come across so far;
in general the preference should still be to ensure that DECL_CONTEXT is
set where possible.
We should be able to distinguish such types by CLASS_TYPE_P, which is
false for them.
Jason