Rust Port: not building on windows

[fahdfady]

🐛 Bug Report

when running cargo build on the rust port on windows-latest this error comes out

     Running `C:\Users\runneradmin\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\rustc.exe --crate-name metacall --edition=2021 src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test --check-cfg cfg(docsrs,test) --check-cfg "cfg(feature, values())" -C metadata=b4bdd0d0207f60b5 -C extra-filename=-74d6ef36fc0f263a --out-dir D:\a\core\core\source\ports\rs_port\target\debug\deps -C incremental=D:\a\core\core\source\ports\rs_port\target\debug\incremental -L dependency=D:\a\core\core\source\ports\rs_port\target\debug\deps --extern metacall_inline=D:\a\core\core\source\ports\rs_port\target\debug\deps\metacall_inline-6f7d944e6cb928d7.dll -l dylib=metacall`
error[E0308]: mismatched types
   --> src\types\metacall_value.rs:165:12
    |
165 |         Ok(value)
    |         -- ^^^^^ expected `i64`, found `i32`
    |         |
    |         arguments to this enum variant are incorrect
    |
help: the type constructed contains `i32` due to the type of the argument passed
   --> src\types\metacall_value.rs:165:9
    |
165 |         Ok(value)
    |         ^^^-----^
    |            |
    |            this argument influences the type of `Ok`
note: tuple variant defined here
   --> /rustc/29483883eed69d5fb4db01964cdf2af4d86e9cb2\library\core\src\result.rs:552:5
help: you can convert an `i32` to an `i64`
    |
165 |         Ok(value.into())
    |                 +++++++

error[E0308]: mismatched types
   --> src\types\metacall_value.rs:168:45
    |
168 |         unsafe { metacall_value_create_long(self) }
    |                  -------------------------- ^^^^ expected `i32`, found `i64`
    |                  |
    |                  arguments to this function are incorrect
    |
note: function defined here
   --> src\bindings.rs:177:12
    |
177 |     pub fn metacall_value_create_long(l: ::std::os::raw::c_long) -> *mut ::std::os::raw::c_void;
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^ -
help: you can convert an `i64` to an `i32` and panic if the converted value doesn't fit
    |
168 |         unsafe { metacall_value_create_long(self.try_into().unwrap()) }
    |                                                 ++++++++++++++++++++

For more information about this error, try `rustc --explain E0308`.
warning: metacall@0.4.3: Using pure Cargo build, searching for MetaCall...
warning: metacall@0.4.3: Searching for MetaCall in: C:\Users\runneradmin\AppData\Local\Metacall\metacall
warning: metacall@0.4.3: MetaCall library not found. Searched in: C:\Users\runneradmin\AppData\Local\Metacall\metacall. If you have it installed elsewhere, set METACALL_INSTALL_PATH environment variable.
error: could not compile `metacall` (lib) due to 2 previous errors

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce

Context (Environment)

Detailed Description

Possible Implementation

[viferga]

I have improved a bit the issue:

error: test failed, to rerun pass `--test inlines_test`
Caused by:
  process didn't exit successfully: `D:\a\core\core\source\ports\rs_port\target\debug\deps\inlines_test-11540998f2b73e3d.exe` (exit code: 0xc0000135, STATUS_DLL_NOT_FOUND)
note: test exited abnormally; to see the full output pass --nocapture to the harness.

There is a way to make the dll into PATH, right now I am using this but is not enough:

#[cfg(target_os = "windows")]
println!("cargo:rustc-env=PATH={}", lib_path.path.display());

This is a way of doing it programatically but it must be added for each test, we can codegen it in the build.rs and add it to each test at the beginning:

#[cfg(target_os = "windows")]
fn add_dll_search_path(path: &str) {
    use std::ffi::OsStr;
    use std::os::windows::ffi::OsStrExt;
    use windows_sys::Win32::System::LibraryLoader::SetDllDirectoryW;

    let wide: Vec<u16> = OsStr::new(path)
        .encode_wide()
        .chain(std::iter::once(0))
        .collect();
    unsafe {
        SetDllDirectoryW(wide.as_ptr());
    }
}

[viferga]

After the changes we did, it is still getting the same error, I am not sure if I should hardcode the PATH in the CI for windows.. or we should find a more elegant solution. Any ideas? @fahdfady