Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go: 1.24 support - Tolerate type parameters on alias types #18585

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

owen-mc
Copy link
Contributor

@owen-mc owen-mc commented Jan 24, 2025

This is a small part of #18306 that can be merged in advance and means that the extractor won't fail on code using type paramters on type aliases, which is a new language feature in go 1.24. It is not tested in this PR as that would involve the test using 1.24, but it is tested in the original PR.

@Copilot Copilot bot review requested due to automatic review settings January 24, 2025 09:43
@owen-mc owen-mc requested a review from a team as a code owner January 24, 2025 09:43
@github-actions github-actions bot added the Go label Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

go/extractor/extractor.go:482

  • The newly introduced code path for type aliases is not covered by tests in this PR. Consider adding tests to verify the functionality of type parameter parent population for alias types.
} else if tp, ok := typeNameObj.Type().(*types.Alias); ok {

Tip: If you use Visual Studio Code, you can request a review from Copilot before you push from the "Source Control" tab. Learn more

@owen-mc owen-mc added the no-change-note-required This PR does not need a change note label Jan 24, 2025
@owen-mc owen-mc changed the title Go: 1.24 support - Allow type parameters on alias types Go: 1.24 support - Tolerate type parameters on alias types Jan 24, 2025
Copy link
Contributor

@smowton smowton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a test case to check what the comment describes re: the proper parent of a type parameter doesn't cause trouble?

For example, I think if we had A with type param T and then type B = A, it sounds like there was a risk that T would have ambiguous parents, A and B?

@owen-mc
Copy link
Contributor Author

owen-mc commented Jan 24, 2025

After staring at it for a long time, I think you're right that we need more of a check for the go 1.23 situation. I think the situation is this:

  • a *types.TypeName is the kind of object for an alias or a defined type.
  • in go 1.23 and before, calling Type() on a *types.TypeName for an alias gave you the type on the rhs of the alias declaration. So it could well be a defined type. I've moved the old check into the first conditional, which is intended just for named types. The second conditional, intended for alias types, won't be triggered in these versions of go.
  • in go 1.24, calling Type() on a *types.TypeName gives you the alias type back again, so that will be caught be the second conditional.

As for tests:

  • If A has a type parameter and you try to write type B = A you get the error "cannot use generic type A[T any] without instantiation" (in 1.23 and 1.24).
  • type B[T any] = A[T] is only valid in go 1.24 (and it is tested in the go 1.24 PR).
  • What you can do is type B = A[int], and that is already tested here.

@smowton
Copy link
Contributor

smowton commented Jan 24, 2025

👍 lmk when ready for re-review re adding an extra check if needed

@owen-mc
Copy link
Contributor Author

owen-mc commented Jan 24, 2025

@smowton I added the extra check already in Retain previous check for alias types. I also ran DCA, which showed nothing significant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Go no-change-note-required This PR does not need a change note
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants