In #70128, we removed the concept of "core types" from the spec; see https://go.dev/blog/coretypes for details. However, there is still a lot of work to be done for x/tools to catch up.
The specified semantics of many operators remain for now equivalent to the old definition under core types. But some operators already have looser semantics that do not require all types in the type set to have a common underlying type. For example, it is legal to call delete(m, key) on m whose type has no core type, so long as each individual type in its type set is a map that supports deletion of that key type. (See #79734 for a specific crash related to this case.)
Every existing use of the CoreType function in x/tools is a potential mistake. CoreType returns nil for types that have no core type, and we need to audit to ensure that the nil case is properly handled or cannot happen (because for example we are processing well-typed code for which a core type is a postcondition of the type checker). If it can happen, then the correct solution is to use NormalTerms to iterate over the type set and to apply some operation to each element of the set. This is often far from straightforward: for example, the condition inspect(CoreType(tx), CoreType(ty)) may now require major restructuring as two nested loops to explore the cross product of two type sets, and that of course introduces an unwanted quadratic (or higher) term to the running time.
@griesemer @mrkfrmn
In #70128, we removed the concept of "core types" from the spec; see https://go.dev/blog/coretypes for details. However, there is still a lot of work to be done for x/tools to catch up.
The specified semantics of many operators remain for now equivalent to the old definition under core types. But some operators already have looser semantics that do not require all types in the type set to have a common underlying type. For example, it is legal to call delete(m, key) on m whose type has no core type, so long as each individual type in its type set is a map that supports deletion of that key type. (See #79734 for a specific crash related to this case.)
Every existing use of the CoreType function in x/tools is a potential mistake. CoreType returns nil for types that have no core type, and we need to audit to ensure that the nil case is properly handled or cannot happen (because for example we are processing well-typed code for which a core type is a postcondition of the type checker). If it can happen, then the correct solution is to use NormalTerms to iterate over the type set and to apply some operation to each element of the set. This is often far from straightforward: for example, the condition
inspect(CoreType(tx), CoreType(ty))may now require major restructuring as two nested loops to explore the cross product of two type sets, and that of course introduces an unwanted quadratic (or higher) term to the running time.@griesemer @mrkfrmn