Skip to content
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

Add language support for Rust #15775

Open
ZackKanter opened this issue Jun 8, 2022 · 6 comments
Open

Add language support for Rust #15775

ZackKanter opened this issue Jun 8, 2022 · 6 comments
Assignees

Comments

@ZackKanter
Copy link

It would be great if Pants added Rust as a supported language!

@siemato
Copy link

siemato commented Jun 10, 2022

you might want to join the project discussions. There are topics for Rust and Cpp. This is a big task though and I think, stabilizing Java related toolchains is even higher on the agenda. They have progressed a lot farther.

@Eric-Arellano
Copy link
Contributor

Agreed, we'd love this.

Check out #15093. @tdyas put some great thought on how to model targets, which is IMO one of the trickier parts of figuring out this change: https://docs.google.com/document/d/1Q5h0PTusb2WyD3EScgeqUxBPF1IuEXCaa3qO31HEHjQ/edit

@siemato
Copy link

siemato commented Jun 13, 2022

Maybe we should move in inverse with LLVM based compilers.

  1. We can reuse large parts of the toolchain for other frontends
  2. The interoperability story between different languages should be a priority
  3. This should be great for caching build artifacts

@Eric-Arellano
Copy link
Contributor

The interoperability story between different languages should be a priority

@siemato could you speak more to this, please? We think a lot about Rust <-> Python interop, e.g. PyO3. But haven't put any Pants design thought into Rust w/ other languages. What does your ideal world look like?

@siemato
Copy link

siemato commented Jun 14, 2022

@Eric-Arellano sure, I'll gladly do. First of all, interoperability issues are, as much as I am aware of, either frontend or (dynamic) linking issues in LLVM land and pretty much always based on being non-hermetic in nature. An example would be C/C++ compilers greeding for their libc. That's, why I would prefer to ignore frontends for now, starting at LLVM-IR level and making sure, LLVM works properly and in a hermetic fashion. Using this foundation, I would try to keep pushing.

One option would be, to use language specific frontends as LLVM-IR 'code generators', then using LLVM as a compiler.
Or we come up with something else alltogether. That's why I brought up Zig's toolchain in the C/C++ discussion thread.

For a short tldr: Zig can compile C/C++, and does so hermetically and decoupled from the target - great for cross compilation. Bazel folks (Uber in particular, contracting the Zig foundation for support) started to use the Zig toolchain to build all their C code.

This affects CFFI for Rust, CGo, generally building projects based on C/C++ in scope of cross compiling to different platforms and different libc (musl/glibc/FreeBSD-libc/...)

I would strongly prefer to keep watching for now, though. As I see it, this doesn't block Rust (being hermetic), but I think it's wiser in the grand scheme, to move from backend to frontend.

@tgolsson
Copy link
Contributor

I've created a topic around a freshly released plugin for Rust support here: #20119

@tgolsson tgolsson self-assigned this Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

4 participants