Internal/unit tests that mock `GotocCtx`

[avanhatt]

It would be nice to have internal unit tests that can call into RMC functions like pretty_name_from_instance. Right now, I think the testing infrastructure only supports running rmc on full *.rs files.

[avanhatt]

Some unit tests on mock objects from core rust for inspiration: https://github.com/rust-lang/rust/blob/289ada5ed41fd1b9a3ffe2b694e6e73079528587/compiler/rustc_mir/src/dataflow/framework/tests.rs#L307

[adpaco]

@bdalrhm has found out that we can support these tests by defining functions with the #[test] annotation and calling ./x.py test -i --stage 1 compiler/rustc_codegen_llvm/

However, in the case of function pretty_name_for_instance (and many others) there is a need of mocking up complex objects to pass them as arguments before calling the function:

    pub fn pretty_name_from_instance(&self, instance: Instance<'tcx>) -> String {
        format!(
            "{}::{}",
            self.tcx.crate_name(instance.def_id().krate),
            with_no_trimmed_paths(|| instance.to_string())
        )
    }

Here, self is a GotocCtx object, which is defined as:

pub struct GotocCtx<'tcx> {
    /// the typing context
    pub tcx: TyCtxt<'tcx>,
    /// the generated symbol table for gotoc
    pub symbol_table: SymbolTable,
    pub hooks: GotocHooks<'tcx>,
    pub type_hooks: GotocTypeHooks<'tcx>,
    /// a global counter for generating unique names for global variables
    pub global_var_count: u64,
    /// map a global allocation to a name in the symbol table
    pub alloc_map: FxHashMap<&'tcx Allocation, String>,
    pub current_fn: Option<CurrentFnCtx<'tcx>>,
}

Of course, it is possile to define GotocCtx instances by mocking up underlying objects, but there is no guarantee that the whole GotocCtx would be valid then. This would probably involve too much effort just to test a single function.

Another option is to dump real GotocCtx objects from a given program and load them in the unit tests. There are two issues with this:

1. The process would be equivalent to test the function on a given program.
2. The dumped objects would remain static, which would not allow us to detect regressions on the compiler front end.

Neither of these options look good to me. These could be alternative solutions:

1. Refactor functions under tests and decouple them so that they do not need complex objects like GotoCtx. This may not be possible for all functions we want to test.
2. Start a new test module that works on the JSON output produced by RMC. This would be similar to what we already do in some tests where we check that a set of lines are present in the CBMC output.

---

Closing this issue as it seems there is no need for this kind of internal tests anymore (testing for dyn trait handling is being done on Rust programs), but we can revisit in the future if needed.