Before I thought of compiling Rust to WebAssembly and then to SWF (aka. ActionScript Bytecode). However, this isn't easy because Rust translated to .wasm loses basic high-level information and generates code full of pointers.
So... I think I might be interested in Rust's HIR, but I'm not sure from where to start.
Basically ActionScript bytecode (aka. the bytecode format from the document "AVM2 Overview") describes something similiar to Java bytecode (.class), except I think it doesn't support nested classes. If I were to compile Rust to ABC, then I'd not use the built-in std dependency and kind of use a dialect of Rust, restraining it with what ActionScript supports.
I want to use Adobe AIR because, differently from browsers, it allows your app to use storage data more freely (compared to web localStorage, IndexedDB and cookies). It supports a flash.filesystem.File type with file:, app: and app-storage: URLs. It's generally a platform comparable to a browser (but goes to other extents and supports native extensions). And starting from 2019, Adobe AIR was handed to another company. I also think it'd be fun to use Rust with it, mainly to re-use the flash.display list. There are parts of the API which I don't like too, but I think it'd be really interesting to try it.
Rust's HIR is pretty much an AST with desugaring, name resolution and macro expansion already performed. I doubt you'll gain much from using Rust's HIR instead of writing your own language.
If you're going to something bytecode-like but want type information, you want another backend to lower the desugared but still type-aware MIR to the appropriate thing.
I'm finding it a bit complicated to understand this docs, is there more information somewhere? When I go to the API docs, I don't see much there. For example, I navigated to rustc_codegen_ssa::mir::statement, clicked CALLSITE and found it's a static of DefaultCallsite type. When I click to see that type, it leads to a 404 page.
Plus, there are only few statics. Anyway, why would I use statics when working the Rust code?
Yeah, those are generated by tracing's logging macros. It's somewhat unfortunate that rustdoc document-private-items documents these statics like this — they're not actually module-level items at all. That's why if you go up a level you'll see multiple identically named statics; this one in particular is defined in FunctionCx::codegen_statement (by the #[instrument] macro).
(Perhaps tracing could mark its injected code #[cfg(not(doc))] as a mitigation... or #[doc(hidden)] might also work, I'm not certain of the interaction between documenting private items and hidden items.)