Skip to content

Perform cross package type analysis #1364

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

Merged
merged 1 commit into from
Mar 24, 2025

Conversation

grantnelson-wf
Copy link
Collaborator

@grantnelson-wf grantnelson-wf commented Mar 5, 2025

These changes are for the 3rd task towards generics

  1. build system needs to be changed to collect generic instance information and propagate it across package boundaries. This would require reorganizing build package into loading all packages first, analyzing them, and then passing to the compiler, which is different from today's behavior where imported packages are loaded and compiled on-demand when compiler needs them. The tricky part here would be making sure build cache accounts for the fact that dependent packages may influence the set of generic instances of the dependency packages. - from this slack comment by nevkontakte

What these changes do

  • This leverages the prior work to making Sources a more important part of the Build process.
    • This add the type information and linkname information into the Sources.
  • This pulls the preparation of the Sources out of the compile phase. During preparation:
    • All the source files are sorted within each package by name
    • The Sources type information and type package are determined and stored in Sources
    • All the Go linknames are gotten
    • All the source files are simplified
    • All the instance information is collected
    • Analysis is run and propagated across package boundaries
  • Once all the sources have been prepared, they can be compiled

@grantnelson-wf grantnelson-wf changed the title [WIP] Extract type checking and analysis from compiler Perform cross package type analysis Mar 5, 2025
@grantnelson-wf grantnelson-wf self-assigned this Mar 6, 2025
@grantnelson-wf grantnelson-wf marked this pull request as ready for review March 6, 2025 23:12
Copy link
Member

@flimzy flimzy left a comment

Choose a reason for hiding this comment

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

I have read through this PR a couple of times, and nothing stands out to me to me as a problem.

Copy link
Member

@nevkontakte nevkontakte left a comment

Choose a reason for hiding this comment

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

Apologies for the delay. Something was bothering me about thing change, but I couldn't quite figure out what exactly. However, I think I have :)

That thing is that build.Session API is still mostly trying to pretend it works on single packages, despite the fact that it loads the full dependency tree and stores it inside. However, in reality we are working on a full program, not a single package.

The dissonance is made worse by the fact that we sometimes synthesize parts of the program (like test packages), but that fact is almost unobservable.

A better API (for testability and understanding both) would be where each processing stage is (at least conceptually) a pure function with its input a full-program representation of the previous stage, and the return value, again, a full program of the next stage. Compare this with today, where are a just passing the reference to an entry package, and keep the majority of the information internally.

So, at some point, we probably should build on the idea you've started with Sources and implement types like LoadedProgram, AnalyzedProgram, CompiledProgram and GeneratedSource.

All that said... From practical perspective, you PR is a fine incremental step forward. Now that I understand what was bothering me, I also know that it's not an immediate concern, just a future direction.

@grantnelson-wf
Copy link
Collaborator Author

Totally, @nevkontakte. I totally agree, that this is not the best solution. I was going for three goals; 1. get it working, 2. do it with least numbers of line changes possible, 3. it must still be maintainable. I'm completely onboard with this being just a stepping stone towards a better design. Thank you for explaining your concern.

I think one thing that would help would be to get the x/tools/go/packages working. That would reduce the "working on single packages" feeling since we'd get all the packages in one go. Also, you're right about using types to enforce the order preparation steps so that it doesn't have as many unenforceable "Do this before..." comments.

@grantnelson-wf grantnelson-wf merged commit 5685251 into gopherjs:master Mar 24, 2025
10 checks passed
@grantnelson-wf grantnelson-wf deleted the breakupCompile3 branch March 24, 2025 19:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants