Looks like the bitflags version bump leads to a dependency on std (see CI errors). We probably need to disable some default features or enable a no_std feature.

Updating tempfile also requires updating rustix. The old rustix version didn't depend on bitflags 2.0, but the new one does. rustix being a std crate, it enables the std feature in bitflags 2.0.
Cargo feature unification makes it so that the features of all dependencies in the whole workspace are unified and so when cargo goes to build our non-std packages, it thinks it needs to build bitflags with std even though that's only required by another package.
There's an accepted RFC to add an option to disable workspace-wide feature resolution, but AFAICT. it hasn't been implemented yet. One can also use cargo-hack to work around this.

The only way to fix this I can think of is to remove the tempfile dependency altogether. We could either continue writing to a file and just create the file ourselves or do the processing in-memory. I have patches for the latter, but I'm a little concerned that some users might want to build large-ish images and they might not like the increased memory usage.

Another thing to keep in mind is that the instant dependency is very likely not even used in practice. We only depend on it because fastrand 1.9.0 depends on it, but even fastrand only uses it when it's being built for non-WASI WebAssembly targets and I seriously doubt that anything is trying to do that.

Yes, it looks like the dependencies updated in this PR have introduced new problems. I am going to close this PR because it does not completely solve the issue.

I think the feature unification only occurs because we run cargo check -all, which builds all packages in the workspace for the host target, including the test kernels. Cargo doesn't unify dependency features across different targets, but it does in this case because we build the test kernels for the host target too.

We don't really need to run a separate check command for the test kernels because the they are already built as artifact dependencies in the dev-dependencies of the main bootloader package. So we can run cargo check --all-targets --workspace --exclude "test_kernel_*" instead and this will still build the test kernels, but this time only for their intended target. This should resolve the feature unification issue because cargo doesn't unify features when builting for different targets.

I'll open a PR for this.

I think the feature unification only occurs because we run cargo check -all, which builds all packages in the workspace for the host target, including the test kernels. Cargo doesn't unify dependency features across different targets, but it does in this case because we build the test kernels for the host target too.

Yes, that's correct.

We don't really need to run a separate check command for the test kernels because the they are already built as artifact dependencies in the dev-dependencies of the main bootloader package. So we can run cargo check --all-targets --workspace --exclude "test_kernel_*" instead and this will still build the test kernels, but this time only for their intended target. This should resolve the feature unification issue because cargo doesn't unify features when builting for different targets.

This should work, but keep in mind that rust-analyzer also uses --all, so if we break --all, this will impact the LSP experience for some (most?) users.

This should work, but keep in mind that rust-analyzer also uses --all, so if we break --all, this will impact the LSP experience for some (most?) users.

Hmm, good point. Only when working on this repo or even if the bootloader crate is used as a dependency?

Only the former.

There is no way to configure rust-analyzer independently of the editior, right? Only e.g. VSCode-specific config.

There is no way to configure rust-analyzer independently of the editior, right? Only e.g. VSCode-specific config.

I don't know, I only use VSCode.

I guess the other option could be to make the test_kernels dir its own cargo workspace. Perhaps that's the cleaner solution? Then we should not need to configure rust-analyzer.

I don't know, I only use VSCode.

Me too. I would be also fine with committing a VSCode-specific config file to the repo that sets the --exclude "test_kernels_*" argument for rust-analyzer.

I guess the other option could be to make the test_kernels dir its own cargo workspace. Perhaps that's the cleaner solution? Then we should not need to configure rust-analyzer.

That's the route I took for https://github.com/freax13/mushroom. Other than having to manage multiple lock files, this works well. I think that rust-analyzer can cope quite well with this, but then again, I might have been using this setup for so long that I've just learned to blend out the rough edges.

BTW, here's the RFC that will eventually fix all of this: rust-lang/rfcs#3692