Compile HIR/THIR/MIR as input into binary

In LLVM, I can easily compile .ll file into binary.

Is it possible to compile Rust's IR as input into binary?

For example, I would like to compile HIR as input.

this is not easily possible. But with MIR you can use std::intrinsics::mir to hand write MIR inside a function body.

So then is it easily possible with MIR but difficult with HIR or THIR?

Note that none of the intermediate formats listed are stable. THIR doesn't even last that long — it only exists for as long as the caller needs it.

What are you trying to accomplish by doing so?

Not the OP, but I could imagine writing an alterative syntax on top of HIR. I doubt it would be all that useful with only having the semantics of Rust, and error reporting would be all screwy, etc...

Alternatively, maybe you could build something like a faster proc-macros?

I want to create a Rust IR generator/mutator and use it to fuzz rustc in order to find bugs such as ICEs(Internal Compiler Errors).

The reason for considering this approach instead of directly generating Rust code is as follows:

  • It takes a lot of time and effort to increase the probability of generating code that compiles.
  • The intention is to focus more on bugs at a lower level, such as optimization, rather than bugs in parts like parsing and desugaring during the Rust code compilation process.

HIR, THIR and MIR have a lot of invariants that are inplicitly upheld by the code that lowers the previous IR to them. Letting a fuzzer generate them would immediately find a lot of crashes due to broken invariants that are entirely unreachable in the surface syntax.

1 Like

Yes, you should fuzz source syntax. Don't fuzz intrinsics::mir as I described above, or any intrinsics.

1 Like

You can probably generate source code from the hir (and maybe mir with more effort) for fuzzing propose.

I tried to apply a methodology similar to Structured Fuzzing of LLVM IR to Rust's IR,

I realized that there are several considerations mentioned in the comments that need to be taken into account.

I need to think about it more and come up with a better approach, thanks.

Check out GitHub - matthiaskrgr/icemaker: automatially find crashes in the rust compiler & tooling and the related projects

1 Like

What exactly does this sentence mean here?

Alternatively, maybe you could build something like a faster proc-macros?

I'm not completely sure, but I was thinking of something like an experimental fork of Rustc that exposes HIR output to proc macros rather than raw TokenStreams. Or I was just getting confused and thought this would let you skip taking a syn dependency with it's early pipelining build time.

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