cmd/compile: clean more up after ssa.Type -> types.Type refactoring

[josharian]

CL 42145 switched package ssa to use types.Type for types. Further cleanup is now possible: Eliminating (in part or in full) ssa.Types, streamlining/eliminating some types.Type methods, moving universe initialization to package types. This is a reminder to do that.

cc @randall77 @mdempsky @griesemer

[mdempsky]

Adding HelpWanted since this is some low hanging fruit that folks interested in stepping into the compiler could easily help with.

[ChrisALiles]

I’d like to have a try at this - your “low hanging fruit” remark gives me some confidence.

[josharian]

Go for it!

Bear in mind that the tree is closed until announced on golang-dev, probably Feb 1. Since these should involve no functional changes, you might find toolstash-check to be helpful. Err on the side of smaller changes rather than one big change; it eases reviewing. If you have any questions, feel free to ask here.

[ChrisALiles]

My investigations so far show me that there are 2 main parts to this - 1) Remove the duplicate type stuff from ssa, which should be “relatively” straightforward 2) Remove the dependencies between types and gc, which seems much less straightforward. I’ve documented my analysis of the the second part - at the risk of appearing “needy”, could I ask for someone to have look at this document lest I stray too far from the desired path? Thanks Chris

…

On 21 Jan 2018, at 4:22 pm, Josh Bleecher Snyder ***@***.***> wrote: Go for it! Bear in mind that the tree is closed until announced on golang-dev, probably Feb 1 <https://github.com/golang/go/wiki/Go-Release-Cycle>. Since these should involve no functional changes, you might find toolstash-check <https://github.com/mdempsky/toolstash-check> to be helpful. Err on the side of smaller changes rather than one big change; it eases reviewing. If you have any questions, feel free to ask here. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20304 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeohTl3oxGWAhD_NjuQoVN6o6R9IN_n3ks5tMsmzgaJpZM4NV_Ht>.

[josharian]

Happy to look. (Expect possible delays from me; my schedule is quite fragmented.)

[ChrisALiles]

Thanks Josh, when you have some time. Another question - I’ve been reading sea code. If the intention is to replace the sea type definitions Bool, Int8 etc with TBOOL, TINT8 …, won’t that mean a huge volume of changes? Is it worth it?

…

On 30 Jan 2018, at 4:55 pm, Josh Bleecher Snyder ***@***.***> wrote: Happy to look. (Expect possible delays from me; my schedule is quite fragmented.) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20304 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeohTrWwIr5Fxpdh9vA3MgQznzC3gQB_ks5tPq7AgaJpZM4NV_Ht>.

[josharian]

Did you mean to attach or link to a document? I don't see it.

It's probably not worth doing a bunch of mass renames, unless it will bring a significant readability improvement. We have done significant renames before, and will surely do some again, when they matter. We've never formalized how it works, but if you think we should do some renames, I'd suggest something like:

• Make a list of renames you want to do.
• Convert that into a script that calls gorename a bunch. Test it out, both that the renames apply cleanly and that the results look good.
• Post that list somewhere, like an issue or golang-dev, for review, since it is easier to review such a list than the resulting CLs.
• Consider asking someone from the core team to apply the renames. (It is a pain to review large automated refactoring changes. This is one of the rare cases in which I treat review requests significantly differently depending on how well I know the author. Known authors can be rubber-stamped, unknown authors require painful manual reviews.)
• Do the renames during a quiet period in the tree. The ideal time is basically right now--right before the tree opens for general changes. Then it is likely to apply cleanly and not disrupt too much other work in progress. There's usually a golang-dev email that goes out before the tree opens to coordinate work such as this.

That's probably more than you wanted to know, but hope it is helpful. :)

[ChrisALiles]

I’ve enclosed a slightly revised version of the document - hopefully you can see it. The aim is to clear up any misconceptions that I might have about this issue. Regards

…

On 2 Feb 2018, at 6:00 am, Josh Bleecher Snyder ***@***.***> wrote: Did you mean to attach or link to a document? I don't see it. It's probably not worth doing a bunch of mass renames, unless it will bring a significant readability improvement. We have done significant renames before, and will surely do some again, when they matter. We've never formalized how it works, but if you think we should do some renames, I'd suggest something like: Make a list of renames you want to do. Convert that into a script that calls gorename <https://godoc.org/golang.org/x/tools/cmd/gorename> a bunch. Test it out, both that the renames apply cleanly and that the results look good. Post that list somewhere, like an issue or golang-dev, for review, since it is easier to review such a list than the resulting CLs. Consider asking someone from the core team to apply the renames. (It is a pain to review large automated refactoring changes. This is one of the rare cases in which I treat review requests significantly differently depending on how well I know the author. Known authors can be rubber-stamped, unknown authors require painful manual reviews.) Do the renames during a quiet period in the tree. The ideal time is basically right now--right before the tree opens for general changes. Then it is likely to apply cleanly and not disrupt too much other work in progress. There's usually a golang-dev email that goes out before the tree opens to coordinate work such as this. That's probably more than you wanted to know, but hope it is helpful. :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20304 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeohTlvmIE3q_4YwzBad85-q94xcelopks5tQgm3gaJpZM4NV_Ht>.

[josharian]

Hmm, I can’t see it. How are you enclosing it? I think github strips email attachments.

[ChrisALiles]

I just attached it as a PDF to the email. It started as a Google doc - can I share that with you somehow? Or is there a better way?

…

On Fri, 2 Feb 2018 at 10:53 am, Josh Bleecher Snyder < ***@***.***> wrote: Hmm, I can’t see it. How are you enclosing it? I think github strips email attachments. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20304 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeohTu3J5QxjzwXVLGV3HAq1FZOSyt1rks5tQk6NgaJpZM4NV_Ht> .

[josharian]

Sharing a google doc is fine. Or paste it into a gist (gist.github.com)? Or probably best, just paste all the contents here.