Unification error using shared types, native function and run_io

[ftilde]

Running the following example:

use gluon::vm::{primitive, record, ExternModule};
use gluon::{import, new_vm, ThreadExt};
use gluon_codegen::{Getable, VmType};

#[derive(Getable, VmType)]
#[gluon(vm_type = "shared_type.SharedType")]
pub enum SharedType {
    One(Box<SharedType>),
    Zero,
}
fn fun(_t: SharedType) {}
pub fn run() -> Result<(), Box<dyn std::error::Error>> {
    let vm = new_vm();
    vm.load_script(
        "shared_type",
        r#"
        type SharedType = | One SharedType | Zero
        { SharedType }
        "#,
    )?;
    import::add_extern_module(&vm, "native_fun", |vm| {
        ExternModule::new(
            vm,
            record! {
                fun => primitive!(1, fun),
            },
        )
    });
    vm.load_script(
        "first_fun_import",
        r#"
        let { fun } = import! native_fun
        27
        "#,
    )?;
    // NOTE: This call is required HERE not before the previous load_script!
    vm.run_io(true);
    vm.run_expr::<()>(
        "second_fun_import",
        r#"
        let { SharedType } = import! shared_type
        let { fun } = import! native_fun
        fun Zero
        "#,
    )?; //Causes unification error
    Ok(())
}

fn main() {
    if let Err(e) = run() {
        panic!("{}", e);
    }
}

Results in the following error message:

thread 'main' panicked at 'error: Expected the following types to be equal
Expected: shared_type.SharedType
Found: shared_type.SharedType
1 errors were found during unification:
The use of self recursion in type `shared_type.SharedType` could not be unified.
- <second_fun_import>:4:13
  |
4 |         fun Zero
  |             ^^^^
  |
', src/main.rs:50:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

It seems like enabling IO between imports of the native function somehow causes the unification to fail. Are the "pre-io" and "post-io" Types internally different somehow?

If anyone else encounters this, moving the run_io up (e.g., directly after creation) seems work around this bug.

[Marwes]

I am pretty sure this is because https://github.com/salsa-rs/salsa (used to cache compilation steps), sees the module loaded with run_io(true) and run_io(false) as different, so it compiles the module twice which creates two SharedType instances.

As long as you always compile modules with a consistent run_io() setting it shouldn't be an issue for the moment at least.

[Marwes]

The good fix here is to specify shared_type as a dependency to the extern module.

        import::add_extern_module_with_deps(
            &vm,
            "native_fun",
            |vm| {
                ExternModule::new(
                    vm,
                    record! {
                        fun => primitive!(1, fun),
                    },
                )
            },
            vec!["shared_type".into()],
        );

That makes the extern module get reloaded as it should when run_io changes to true.

Ideally this manual step should not be necessary though but the changes may be a bit tricky.