Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: invalid algorithm table for some types #17752
The failures at 1.7 & tip are the result of explicit checks; the code barfs because the key does not have a hash algorithm.
I suspect the problem is that during compilation of
@josharian No, I'm happy to dig into this.
So the issue is when we're writing out reflect metadata for types, we use the same link symbol regardless of whether Noalg is set, but we generate different contents depending on Noalg (namely whether we provide hash/eq function pointers). The consequence is everywhere we set Noalg on compiler-generated types, we're potentially poisoning any user types that happen to be identical.
It's just that the types we set Noalg on are rarely used as map keys or stored into interfaces and compared for equality, assuming they collide at all. Aside from the bucket arrays discovered above, the other instances are all structs (and one slice, but Noalg is redundant on slices anyway).
I think making Noalg work 100% correctly requires linker support. We probably need to generate separate symbols for the Noalg variants. Later at link-time we could recognize if we have both Noalg and !Noalg variants, and use only the !Noalg variant.
In the mean time, I think the quick fix is to just not set Noalg on the bucket arrays. I'll send a CL.
Instead, could we add names to the noalg types? That would make them distinct from any user types.
It would cost some space for the names, but we would save the space for the hash/eq code which is probably larger.
We'd need unique names, but that shouldn't be too hard (noalg.# where # is a unique id in the package).