Tracking Issue for -Z codegen-backend

[XAMPPRocky]

This is a tracking issue for the -Zcodegen-backend compiler flag.

rustc today only supports one stable backend ("llvm"), but it has many unstable backends.

In the future, it will support multiple stable backends.

Our plan is that the stable backends will all be allowlisted in the compiler. The general pattern will be that every stable backend will be denoted by an identifier with no . in its name (e.g. "cranelift", "gcc", "llvm"). When we start reaching a point where one of the alternative backends is getting close to being ready to stabilize, we will then discuss how to offer a stable form of this flag (i.e. -C codegen-backend flag).

Meanwhile, the -Z codegen-backend flag will always unstably support an interface for connecting to an arbitrary backend loaded as a dynamic library, as described below.

---

This flag unstably allows you specify a path to a dynamic library containing a function named __rustc_codegen_backend with a signature of fn() -> Box<dyn rustc_codegen_ssa::traits::CodegenBackend> to use as code generation backend at runtime. (CodegenBackend trait)

Example

use rustc_codegen_ssa::traits::CodegenBackend;

struct MyBackend;

impl CodegenBackend for MyBackend {
   // Implement codegen methods
}

#[no_mangle]
pub fn __rustc_codegen_backend() -> Box<dyn CodegenBackend> {
    Box::new(MyBackend)
}

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Implementation history

• Initial Implementation Allow runtime switching between trans backends #45684
• Add codegen-backend to deps Add -Z codegen-backend dylib to deps #77565

[pnkfelix]

Discussed at backlog bonanza

https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bplanning.20meeting.5D.202022-10-21/near/305370223

We won't need a stable form of this flag until we have a alternative backend that is far enough along to be a candidate to be stabilized (i.e., its "blocked" on that issue, and thus impl-incomplete). Once we do, then we'll figure out whether we need two tracking issues (one for the stable parts of this, and another for the perma-unstable parts), or if we'll just have the one perma-unstable tracking issue.

[pnkfelix]

@rustbot label: S-tracking-impl-incomplete