Adding new features to rustc_llvm

[sanxiyn]

Recently murath submitted a pull request adding a new feature to rustc_llvm crate.

The added feature is not directly needed by rustc. @nrc opined that rustc_llvm should support features directly needed by rustc, and no more. And that more fully featured LLVM binding should be published on crates.io.

That is reasonable for people who want to use LLVM. But as murath replied on GitHub, it is of no use for people who want to use LLVM used by Rust. As far as I know, two different versions of LLVM have no compatibility guarantee whatsoever.

Possible solutions:

• Add features to rustc_llvm even if not needed by rustc. This is the easiest in the short term, but not ideal. For example, this ties LLVM binding to Rust release cycle.
• Fix LLVM version used by Rust, so other people can write code against it. To be useful, this ideally should be the version widely available as binary. But “system LLVM” versions do not agree between systems. Also, I think we would like to reserve the right to patch LLVM to fix bugs, instead of working around bugs. Although we have no such bug fixes right now, we had them in the past.
• In Rust binary releases and Rust installs from source, provide LLVM library one can link against. That is, install.sh and “make install” installs, say, libllvmForRust.so, and librustc_llvm-$hash.so uses it, instead of what is done now, static linking. JavaScriptCore does something similar: libllvmForJSC.so.

Thoughts?

[Manishearth]

people who want to use LLVM used by Rust.

You can just create a separate crate that has proper LLVM bindings to Rust’s LLVM fork.

[murarth]

To give a bit of detail (and to be a bit pedantic), the feature was added about six months ago, but nobody noticed it at the time. The recent pull request is a bugfix for Mac and a minor change to the public-facing API. It’s a thin wrapper around LLVM’s ExecutionEngine, which performs in-memory linking on code generated by rustc. It is essential to the operation of rusti (or any other Rust REPL).

I understand the need to keep core rustc code focused on its own purpose. I just don’t see a clear way of accessing these APIs outside rustc_llvm. Enabling an external crate to provide bindings to Rust’s LLVM fork seems like a good option. This process would also need to install Rust LLVM’s headers to enable the introduction of C++ code when necessary (as it is in this case).

[sanxiyn]

You can just create a separate crate that has proper LLVM bindings to Rust’s LLVM fork.

This assumes “LLVM used by Rust” is same as “Rust’s LLVM fork”, which is false for installs compiled with system LLVM, including current Debian and Fedora packages. In the future, this will be more false.

[nrc]

I propose accepting the patch for now as it is a bug fix. Does anyone object to that (short term)?

But I would like to understand the issues here a bit better and have a proper discussion. It seems suboptimal to have to bundle these things with rustc. I would have thought there is some solution which involves an external crate - could they be bundled with rusti rather than rustc?

Could we make rusti use rustc as a library (using the driver API) and do the llvm execution engine stuff in rusti?

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.