go/types, types2: 'any' in go/types.Universe should be of type Alias

[findleyr]

Just noticed that the predeclared types any, byte, and rune in go/types.Universe are not actually of type go/types.Alias. This matters: I noticed it while working on type writing for the x/tools inliner.

I'll put together a fix. I would not be surprised if additional tests fail as a result of this fix, since this would be the first time we have an Alias type in the universe scope.

(EDIT: per discussion, let's just fix this for any. Basic types are special anyway).

CC @griesemer @adonovan

[findleyr]

Note: this poses a rather unfortunate problem for switching GODEBUG values inside tests.

[gopherbot]

Change https://go.dev/cl/580355 mentions this issue: go/types, types: make any, byte, and rune actual Alias types.

[findleyr]

@griesemer @adonovan after staring at the implications of this for a minute, I think the only way to do it properly is to insist that the only way to change GODEBUG=gotypesalias is at startup. There's no way that switching in tests can work when universeAny, universeByte, and universeRune are written to types.Universe and types.Typ.

@timothy-king has created a GODEBUG=gotypesalias=1 builder, and we should use that technique for creating a GODEBUG=gotypesalias=0 builder.

[adonovan]

Just noticed that the predeclared types any, byte, and rune in go/types.Universe are not actually of type go/types.Alias. This matters: I noticed it while working on type writing for the x/tools inliner.

Why does it matter exactly? The defined types string and int are not actually represented like other defined types astypes.Named, because they don't have a declaration or TypeName. It seems to me that byte falls into a similar category.

I'll put together a fix. I would not be surprised if additional tests fail as a result of this fix, since this would be the first time we have an Alias type in the universe scope.

What would be the fix? What would the TypeName be for a universal Alias?

@griesemer @adonovan after staring at the implications of this for a minute, I think the only way to do it properly is to insist that the only way to change GODEBUG=gotypesalias is at startup. There's no way that switching in tests can work when universeAny, universeByte, and universeRune are written to types.Universe and types.Typ.

Arguably this is evidence that it's not the right fix.

@timothy-king has created a GODEBUG=gotypesalias=1 builder, and we should use that technique for creating a GODEBUG=gotypesalias=0 builder.

We should flip that builder to "0", since we don't need a "1" builder: it's the default at tip.

[findleyr]

Why does it matter exactly?

The spec says that they are aliases, and there are various places where we need to check for distinguished pointers to print the right name. (search for types2?.Universe.Lookup("any") to find these special cases). Several of those places also have apologies that the "hack" wouldn't be necessary with proper alias support. Now we have that support.

It is inconsistent for them not to be Aliases. Why shouldn't we fix this properly?

What would be the fix? What would the TypeName for a universal Alias?

A new TypeName? I don't understand the question.

Arguably this is evidence that it's not the right fix.

I don't see how that follows. We have a global that uses the new API. Any time a global is affected by a GODEBUG value, it seems that such a fix would be required. I don't understand the philosophical point.

[adonovan]

A new TypeName? I don't understand the question.

Sorry, I was under the misapprehension that all TypeNames had valid positions, but of course that's not true for all the built-in types. Ignore me.

[findleyr]

Thanks. Will wait for @griesemer to opine before spending too much more time here. See the associated CL for the proposed fix. It wasn't hard to get go/types/types2 tests passing, and I suspect just a few more changes are required in the compiler / importers.

Do we want to do this? It's now or never, I suppose.

Aside:

The defined types string and int are not actually represented like other defined types astypes.Named, because they don't have a declaration or TypeName

FWIW, I think that's no problem. Basic types are defined types. But byte and rune are aliases, and suffer from the same loss of information as other aliases.

Put differently, don't we eventually want the definition of TypeName.IsAlias to be _, ok := obj.typ.(*Alias); return ok?

[adonovan]

Do we want to do this? It's now or never, I suppose.
Put differently, don't we eventually want the definition of TypeName.IsAlias to be _, ok := obj.typ.(*Alias); return ok?

Yeah, it's definitely a simpler representation. The question is how much churn will it generate. Only experience will tell.

[findleyr]

Hmm, well byte and rune are distinguished Basic types, i.e. their type carries their name. Therefore it is less important to make this change for them than for any.