Switch from Rust nightly to Rust stable

[jhaye]

The only reason remaining why we use Rust nightly is because only on this release channel cargo supports setting an output dir. This was previously discussed here: https://github.com/lf-lang/reactor-rust/issues/15

I have implemented the functionality in Kotlin code by copying the generated binary to the designated output dir. This allows us to get rid of the Rust nightly requirement.

[cmnrd]

Looks great! Do you have an idea why the rust tests fail though? We have a lot of errors like this: "/home/runner/work/lingua-franca/lingua-franca/test/Rust/src-gen/ReactionLabels/target/debug/reaction_labels: The source file doesn't exist." in the log.

[jhaye]

I have no clue why this is failing. Looking at how the code generation is reported, it should be building the binaries at exactly the place where it reports no file exists.

[jhaye]

Another possibility that I have eliminated: I thought it might be that this is because CI jobs are run with Rust Nightly exclusively, but with Nightly as default it still works on my machine.

[cmnrd]

On my end also everything works fine with both the stable and nightly toolchains. I am not sure what is happening here and its a pain to debug these CI jobs. I guess our best shot is to add a few ls commands to see what the actual directory structure is. I will give this a shot

[jhaye]

Looking at the Windows tests failing, I hadn't considered that on Windows compilation produces .EXE files.

[cmnrd]

Ah, ok so that was the issue with Windows. OK :)

So I found that somehow the checked in Cargo.toml in src-gen broke the compilation setup. I don't fully understand why, but removing it fixes the problem. I could actually reproduce the original problem locally when the Cargo.toml is checked out.
Removing the Cargo.toml indeed increases the CI run time, but I think it is still Ok.

I think if we want to use the top-level Cargo.toml, we should probably code generate it and find a general solution.

[jhaye]

Okay, I'll keep that in mind. Thank you for debugging! I will fix up this PR tomorrow so that we can finally merge it.

[cmnrd]

Looks like the Windows job runs out of disk space... I guess we will have to fix the Cargo.toml that I deleted so that reactor-rs is not build X times. But I don't know where the problem lies with the original Cargo.toml

[jhaye]

I think I understand what the problem is here, the root of a workspace is usually where the target directory is put when building.

As it says in the Cargo book:

All packages share a common output directory, which defaults to a directory named target in the workspace root.

I have an idea how to fix this issue. Cargo exposes several environment variables when building, which can also be got via cargo metadata. The RustValidator class already does this to some degree, I would just have to expose it via API and add the CARGO_TARGET_DIR to it and then retrieve the target directory through that.

[jhaye]

The Rust tests are passing now on every platform.

[cmnrd]

Looks great! Thanks for fixing everything!