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.
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:
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.
Yes, you should fuzz source syntax. Don't fuzz intrinsics::mir
as I described above, or any intrinsics.
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
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.