Hi,
Now I've finished the package types2 for typecheck logic, and continue the
journey to next step: IR generation(directory: cmd/compile/internal/ir/).
It seems the ir package is a new abstract layer created during the refactor
process of types2, and it's main purpose is to translate the AST to IR
Tree. Before jumping into the code details, I would like to ask for some
help from the community for the following questions:
1. In current typechecker(cmd/compile/internal/typecheck), the ir.Node tree
is built along with the process of typecheck, those two processes are mixed
with each other. Why and what's the design thoughts of creating a new layer
named ir?
2. Currently package ir involves a lot of code of package
types(cmd/compile/internal/types/) and package
noder(cmd/compile/internal/noder/), which is used by the current
typechecker(cmd/compile/internal/typecheck). If the Go team will replace
types with types2 and abandon the current typechecker in the future, can I
understand this "mixed-up style code" as a transitional stage to connect
types2 to current typechecker for now? And there will be big changes for
this part? If so, what's the plan?
3. If I want to write an article about IR generation, what's the best
summary of topics for this phase? What I summarized now are:
1). Translate AST to IR Tree;
2). Analysis stack/heap usage for variables;
3). Handle generic instantiations;
Are there other important topics/purposes I'm missing?
If I have any understanding errors, please help me to point them out; and
if there's anything import you think I'm missing, or you think it's helpful
to me, please tell me as well.
Thanks for any help and tips.
On Monday, March 1, 2021 at 2:40:25 AM UTC+8 Ian Lance Taylor wrote:
> On Sun, Feb 28, 2021 at 7:04 AM zhz shi <messi...@gmail.com> wrote:
> >
> > According Russ's plan(replacing cmd/compile/internal/types with types2)
> and the discussion topic Jeremy Faller posted, can I understand it as that
> check2 will be the entry of new and default typechecker in the future(with
> the release of 1.18 one year later)? And the current type-checking code
> will be removed at the same time? If so I think I'd better to use master
> branch for learning.
>
> That is likely but not certain.
>
>
> > And one more question please. I found there's copy of lex/parser and AST
> dcls under https://github.com/golang/go/tree/master/src/go as public API,
> why the compiler doesn't reuse this part of code, but keep a separate copy?
>
> The go/parser and related packages fall under the Go 1 compatibility
> guarantee, which makes it hard to update them as we learn more about
> what the compiler needs. Although there is duplicate code, it seems
> simpler overall for the compiler to have its own parser.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/fb0efef8-162c-4dcf-bc69-c91724a475a0n%40googlegroups.com.
