Remove LLVM dependency from front end

[koliyo]

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.

[kyouko-taiga]

For the Hylo LSP server we only need the front end of the compiler.

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?

[koliyo]

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.

• Mac, single binary, swift runtime libraries will be available
• Linux, build fully static library, with swift runtime embedded.
• Windows, not sure if building static library is possible (?), right now I copy the swift runtime dlls as part of the distribution artifacts.

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.

[kyouko-taiga]

Thanks a lot for your answers and sorry for the delay to come back.

An alternative approach would be that the LSP depends on an existing Hylo compiler installation, but this Hylo distribution is not available yet.

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.

And I still prefer if the hylo LSP would be self contained, but that is up for discussion.

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.

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.

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.

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.

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.