IDE issues

[hyperswine]

any plans to make integration with e.g. vscode + rust analyzer better?

[phip1611]

Hi @hyperswine
Could you please be a little bit more specific what issues you are encountering?

As uefi-rs is a nostd+alloc library and uses procedural macros, IDE auto completion support is not as first class as for regular std crates. However, this is a general problem of the ecosystem and its tooling, not of uefi-rs in particular.

What specific things are you missing?

[hyperswine]

Im getting random errors and certain features like run test on top of a unit test does not work

[phip1611]

This is independent from vscode or rust analyzer. You can execute tests with cargo xtask test. You can find more information here https://github.com/rust-osdev/uefi-rs/blob/main/CONTRIBUTING.md

The reason for this is that this is a no-std crate. All no-std crates need special handling for executing tests

Does this help you?

[hyperswine]

Well that helps, but im specifically looking for a better IDE developement experience. All good since no std is a second class citizen i suppose

[nicholasbishop]

I admit IDE support is something of a blind spot for me. Just as a matter of personal preference I don't use rust analyzer or anything like that, so it didn't occur to me that we even have a problem here.

I suspect that maybe some of the errors are related to us using -Zbuild-std; there is an open MCP to raise the uefi targets to tier 2, and you can follow #504 to see when uefi-rs is updated after that happens.

I'm going to reopen this for now, when I find some time I'd like to play around with vscode and see what all the errors look like, and see if there's anything we can do to make it better (either in uefi-rs directly, or issues in rust-analyzer we can link to, or maybe instructions for how to configure the tools to understand this project better...)

[nicholasbishop]

Finally got around to taking a look at this. I don't have much in the way of solutions, but here are some notes for future travelers:

For my test case, I started with the template app. I made a copy of that directory and loaded it into vscode with the rust-analyzer extension installed.

The first error I ran into is that rust-analyzer wouldn't run at all due to .cargo/config.toml containing -Zbuild-std stuff, which requires a target, but rust-analyzer doesn't know which target to build. This can be resolved by adding this to the project's .cargo/config.toml:

[build]
target = "x86_64-unknown-uefi"

Or, for a solution scoped just to vscode, adding this to the project's .vscode/settings.json:

{
    "rust-analyzer.cargo.target": "x86_64-unknown-uefi"
}

The next error I saw was Can't find crate for 'test'. As described in that link, this can be resolved with a setting in the project's .vscode/settings.json:

{
    "rust-analyzer.checkOnSave.allTargets": false
}

With that change rust-analyzer seems to be working; hovering over types and such gives doc tooltips, and making an intentional mistake such as typing Handlex and saving shows an error and suggests that maybe I meant Handle.

I'm not sure how best to fix running tests. I think ideally the tests would be run against the host target; we do that with cargo xtask test in uefi-rs for example. Of course, that limits the kinds of tests that can be run; you might want something that runs under QEMU to test actual UEFI stuff depending on your use case (which we do with the separate uefi-test-runner package in uefi-rs).

That's as far as I got with this. I'll re-close the issue since I don't know if there's much more we can do. At least things should get a bit better if we get the UEFI targets to tier 2 so that -Zbuild-std isn't needed anymore.