c++: spec_hasher and TYPENAME_TYPE resolution [PR95223]
After enabling sanitization of the specialization tables, we are
triggering one of the hash table sanity checks in the below testcase.
The reason is that when looking up the specialization j<int> in the
type_specializations table, the sanity check finds that the existing
entry j<n<t>::m> compares equal to j<int> but hashes differently.
The discrepancy is due to structural_comptypes looking through
TYPENAME_TYPEs (via resolve_typename_type), something which
iterative_hash_template_arg doesn't do. So the TYPENAME_TYPE n<t>::m is
considered equal to int, but the hashes of these two template arguments
are different.
It seems wrong for the result of a specialization table lookup to depend
on the current scope, so this patch makes structural_comptypes avoid
calling resolve_typename_type when comparing_specializations.
In order for the below testcase to deterministically trigger the
sanitization error without this patch, we also need to fix the location
of the call to hash_table::verify within hash_table::find_with_hash.
gcc/ChangeLog:
PR c++/95223
* hash-table.h (hash_table::find_with_hash): Move up the call to
hash_table::verify.
gcc/cp/ChangeLog:
PR c++/95223
* typeck.c (structural_comptypes): Don't perform
context-dependent resolution of TYPENAME_TYPEs when
comparing_specializations.
gcc/testsuite/ChangeLog:
PR c++/95223
* g++.dg/template/typename23.C: New test.