|
From: | Pierrick Bouvier |
Subject: | Re: [RFC PATCH v1 0/6] Implement ARM PL011 in Rust |
Date: | Tue, 11 Jun 2024 08:32:16 -0700 |
User-agent: | Mozilla Thunderbird |
On 6/11/24 02:21, Alex Bennée wrote:
Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:On 6/10/24 13:29, Manos Pitsidianakis wrote:On Mon, 10 Jun 2024 22:37, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:Hello Manos,<snip>Excellent work, and thanks for posting this RFC! IMHO, having patches 2 and 5 splitted is a bit confusing, and exposing (temporarily) the generated.rs file in patches is not a good move. Any reason you kept it this way?That was my first approach, I will rework it on the second version. The generated code should not exist in committed code at all. It was initally tricky setting up the dependency orders correctly, so I first committed it and then made it a dependency.Maybe it could be better if build.rs file was *not* needed for new devices/folders, and could be abstracted as a detail of the python wrapper script instead of something that should be committed.That'd mean you cannot work on the rust files with a LanguageServer, you cannot run cargo build or cargo check or cargo clippy, etc. That's why I left the alternative choice of including a manually generated bindings file (generated.rs.inc)Maybe I missed something, but it seems like it just checks/copies the generated.rs file where it's expected. Definitely something that could be done as part of the rust build. Having to run the build before getting completion does not seem to be a huge compromise.<snip> As long as the Language Server can kick in after a first build. Rust definitely leans in to the concept of the tooling helping you out while coding. I think for the C LSPs compile_commands.json is generated during the configure step but I could be wrong.
Yes, meson generates it.I agree having support for completion tooling is important nowadays, whether in C or in Rust.
[Prev in Thread] | Current Thread | [Next in Thread] |