Go: Support 1.23 (Transparent aliases)

[mbg]

This PR is an alternative to the line of work in #17058 which tries to keep the changes required to tolerate Go 1.23 more minimal. The main difference is that in #17058 we explicitly extract Alias types, store them in the database, and then consequently have to deal with type equality issues that arise from this. In contrast, we do not explicitly extract the Alias types in this PR and instead just use the Go compiler to resolve them to their underlying types directly. This has the benefit that much fewer changes are needed to tolerate Go 1.23 extraction and that the behaviour is the same as before Go 1.23. The downside is that no information about aliases is available to query writers.

[smowton]

I think you will have a problem with the multiple fields (objects, in CodeQL Entity) representing the same struct-type's field.

For example, if we have

struct { x int }

type IntAlias = int
struct { x IntAlias }

Then we will call LookupObjectID twice for the two distinct objects (in Go 1.22 there would only have been one), and thanks to the extractor's ScopedObjectID routine I believe we will assign it different field IDs (I think we'll go down the FreshID path since fields don't directly exist at package scope) and fail to relate accesses to one object with the other.

Potential difference between the two approaches here: because you're conflating the two struct types in extractType, fieldstructs will only get populated for one of the two field objects.

[smowton]

Confirmed the above is not in fact a problem: because more than one type maps onto the same TRAP label (e.g. struct { x int } and struct { x IntAlias } will both individually go through extractType, because the memoisation there is keyed on the type (which is different) not its label (which is the same, being calculated with transparent aliases). This results in duplicate extractions, but no database inconsistencies since the trap import phase cleans up the duplicates. We may find extraction is substantially slowed down though, in which case we should suppress unnecessary re-extraction, e.g. by checking after label calculation whether a type with that label has in fact already been extracted.

[owen-mc]

I think this is all redundant and we can just use types.Unalias. But this can be done in a follow-up PR.

Suggested change

	// Determines whether the given type is an alias.
	func isAlias(tp types.Type) bool {
	_, ok := tp.(*types.Alias)
	return ok
	}
	// If the given type is a type alias, this function resolves it to its underlying type.
	func resolveTypeAlias(tp types.Type) types.Type {
	if isAlias(tp) {
	return types.Unalias(tp) // tp.Underlying()
	}
	return tp
	}

[mbg]

Well spotted. Yes, none of this is necessary anymore with the current version of this PR since Unalias implements the same logic. Agree that we can remove it later since it doesn't impact the behaviour.

The merge-base changed after approval.

[owen-mc]

Now that 1.23.1 has been released, fixing a crash bug which was affecting us, shall we update to that?

[mbg]

The CI failure for "Go Resolve Build Environment Tests" is expected until the corresponding, internal PR has been merged. QA experiment results look good. Merging now.