-
Notifications
You must be signed in to change notification settings - Fork 59
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
Remove LLVM dependency from front end #1074
base: main
Are you sure you want to change the base?
Remove LLVM dependency from front end #1074
Conversation
792a941
to
b8a81f6
Compare
While that is currently true, I don't think it will remain so in the future. I'm planning to use LLVM as a JIT compiler to evaluate compile-time expressions during type checking. Is the LLVM dependency blocking your progress on the LSP implementation? |
Ok, yeah the compile time JIT evaluation makes a lot of sense for a modern programming language for sure! For the LSP development it is mainly an issue of packaging the vscode extension + LSP for end user distribution. My current approach is that the LSP server should be self contained, and not depend on specific libraries being installed on the user machine. And LLVM adds a pretty large set of explicit and implicit libraries as dependencies. An alternative approach would be that the LSP depends on an existing Hylo compiler installation, but this Hylo distribution is not available yet. And I still prefer if the hylo LSP would be self contained, but that is up for discussion. Anyway, without LLVM the hylo LSP distribution is relatively straightforward right now.
LLVM will add quite a lot to this, just the llvm.dylib on my mac is 145MB, and it has additional transitive dependencies. Additionally there is some reduction in overhead in CI workflows, avoiding installation of LLVM and some reduced compilation time. But the CI setup is manageable, that is not the main concern. Anyway, I think I will use the LLVM-free build for now, either if the PR is merged, otherwise I will keep this patch in my fork. And when the JIT part of the frontend becomes implemented I can revisit this topic. As always, windows is the most trouble since it does not have any defacto concept of package management. On linux we could probably use existing package managers, and on Mac maybe assume some homebrew environment. This will need some further discussion and design at some point. |
Thanks a lot for your answers and sorry for the delay to come back.
I like this suggestion. I think we should start exploring how to make that distribution. There's been some talks with @nickpdemarco at some point. I can't take the lead on this task but happy to assist in any way I can.
My sense is that if you're developing Hylo you'll need a compiler anyway. So I feel justified asking people to refer to their local toolchain to get a VScode extension running.
That is fair. The JIT integration is not very far on the roadmap by the way. Once we've nailed necessary support for decent generics I'm planning to look into generic value arguments.
As I personally don't want to install Homebrew on my system I would be reluctant to assume such an environment for others. Perhaps we could stand up a bare bone installation script for macOS and Windows (and even Linux). That thing could grow with community contributions as problems show up. |
For the Hylo LSP server we only need the front end of the compiler. This would also remove the dependency on LLVM, both for building, and especially as runtime link dependency.
In order to remove LLVM from Hylo Core I have copied the enum types used
Core.NativeInstruction
In addition I have added a
HyloFrontEnd
build product.