-
Notifications
You must be signed in to change notification settings - Fork 569
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
Conversation
706c883
to
857fba9
Compare
857fba9
to
887f51e
Compare
There was a problem hiding this 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.
There was a problem hiding this 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.
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 |
These changes are for the 3rd task towards generics
What these changes do