[REG2.111] -allinst can cause corrupt TypeInfo_AssociativeArray symbols #21359
Description
bla.d:
void registerAll() {
import carbon; // must be nested apparently
}carbon.d:
struct SumType(Types...)
{
static foreach (T; Types)
T values_;
}
SumType!(string[int]) convertObserver;
void hackAroundLinkerError() {
auto t = typeid(const(immutable(char)[][])); // NOTE: replacing `immutable(char)[]` with `string` makes a difference!
}Now the fun part, using DMD v2.111.0 - checking the TypeInfo for string[int] (mangled as _D14TypeInfo_HiAya6__initZ). Without -allinst:
$ dmd -c bla.d
$ nm bla.o | grep _D14TypeInfo_HiAya6__initZ
# => okay, no symbols as expected - we compile a function with a nested import, no actual body
Now with -allinst:
$ dmd -c bla.d -allinst
$ nm bla.o | grep _D14TypeInfo_HiAya6__initZ
0000000000000000 V _D14TypeInfo_HiAya6__initZ
0000000000000000 V _D14TypeInfo_HiAya6__initZ
0000000000000000 V _D14TypeInfo_HiAya6__initZ
# => oh wow, 3 definitions for the same symbol in the same object file?!
$ objdump -r -s --section=.data._D14TypeInfo_HiAya6__initZ bla.o
RELOCATION RECORDS FOR [.data._D14TypeInfo_HiAya6__initZ]:
OFFSET TYPE VALUE
0000000000000000 R_X86_64_64 _D25TypeInfo_AssociativeArray6__vtblZ
0000000000000000 R_X86_64_64 _D25TypeInfo_AssociativeArray6__vtblZ
0000000000000000 R_X86_64_64 _D25TypeInfo_AssociativeArray6__vtblZ
0000000000000008 R_X86_64_64 _D12TypeInfo_Aya6__initZ
0000000000000008 R_X86_64_64 _D12TypeInfo_Aya6__initZ
0000000000000010 R_X86_64_64 _D12TypeInfo_Aya6__initZ
0000000000000010 R_X86_64_64 _D10TypeInfo_i6__initZ
0000000000000010 R_X86_64_64 _D10TypeInfo_i6__initZ
0000000000000018 R_X86_64_64 _D62TypeInfo_S6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn6__initZ
0000000000000018 R_X86_64_64 _D62TypeInfo_S6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn6__initZ
0000000000000018 R_X86_64_64 _D10TypeInfo_i6__initZ
0000000000000020 R_X86_64_64 _D62TypeInfo_S6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn6__initZ
# => oh wow, something is obviously extremely wrong!
Comparing with v2.110 (where the symbol is mangled as _D15TypeInfo_HixAya6__initZ?):
$ nm -U bla.o.allinst.110 | grep TypeInfo
0000000000000000 V _D13TypeInfo_xAya6__initZ
0000000000000000 V _D15TypeInfo_HixAya6__initZ
0000000000000000 V _D15TypeInfo_xHiAya6__initZ
$ nm -U bla.o.allinst.111 | grep TypeInfo
0000000000000000 V _D11TypeInfo_xi6__initZ
0000000000000000 V _D13TypeInfo_xAya6__initZ
0000000000000000 V _D14TypeInfo_HiAya6__initZ
0000000000000000 V _D14TypeInfo_HiAya6__initZ
0000000000000000 V _D14TypeInfo_HiAya6__initZ
0000000000000000 V _D62TypeInfo_S6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn6__initZ
0000000000000000 W _D6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn11__xopEqualsMxFKxSQCtQCp__TQBrTiTQBoZQCbZb
0000000000000000 W _D6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn9__xtoHashFNbNeKxSQCsQCo__TQBqTiTQBnZQCaZm
Compiling carbon.d with the actual code on the other hand works fine, and -allinst doesn't affect the emitted TypeInfo symbols AFAICT. For reference:
$ nm -U carbon.o.110 | grep TypeInfo
0000000000000000 V _D13TypeInfo_xAya6__initZ
0000000000000000 V _D14TypeInfo_AxAya6__initZ
0000000000000000 V _D14TypeInfo_xAAya6__initZ
0000000000000000 V _D15TypeInfo_HixAya6__initZ
0000000000000000 V _D15TypeInfo_xHiAya6__initZ
0000000000000000 V _D37TypeInfo_S6carbon__T7SumTypeTHiAyaZQp6__initZ
$ nm -U carbon.o.111 | grep TypeInfo
0000000000000000 V _D11TypeInfo_xi6__initZ
0000000000000000 V _D13TypeInfo_xAya6__initZ
0000000000000000 V _D14TypeInfo_AxAya6__initZ
0000000000000000 V _D14TypeInfo_HiAya6__initZ
0000000000000000 V _D14TypeInfo_xAAya6__initZ
0000000000000000 V _D37TypeInfo_S6carbon__T7SumTypeTHiAyaZQp6__initZ
0000000000000000 V _D62TypeInfo_S6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn6__initZ
0000000000000000 W _D6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn11__xopEqualsMxFKxSQCtQCp__TQBrTiTQBoZQCbZb
0000000000000000 W _D6object25TypeInfo_AssociativeArray__T5EntryTiTAyaZQn9__xtoHashFNbNeKxSQCsQCo__TQBqTiTQBnZQCaZm
For a Symmetry code base, this regression means we get a segfault immediately at program startup, when generating an AA literal: symmetryinvestments/dmd-umbrella#6 (comment)