djmcgill / form Goto Github PK

#6 is working great and were hoping to release a crate based on this.

Any chance of a point release?

Thanks!

Now that this crate is seeing some use (and contributions!) by people other than myself, the lack of any CI setup to build and test it isn't really ideal.

Ideally the integration test would run form given a checked-in and pregenerated output from svd2rust and then check that it produces that something cargo will accept.

Some filenames cannot be used on windows, having modules separated into file with these names when they have such names makes the resulting code unusable on windows.

See the bullet point for reserved names at https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions

Problem

Consider the following two source files in the same directory, lib.rs and foo.rs:

lib.rs:

use foo::*;
pub mod foo;

foo.rs:

struct Bar;

When trying to split them, form panics because it attempts to unwrap a None value:

William@DESKTOP-H0PMN4M MINGW64 ~/Projects/MCVE/form-mod
$ form -i lib.rs -o src/
[2021-04-14T16:45:09Z INFO  form::util] Started parsing the input as Rust. This can take a minute or two.
[2021-04-14T16:45:09Z INFO  form::util] Finished parsing
[2021-04-14T16:45:09Z INFO  form::util] Prepared target directory src/
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/760ce94c69ca510d44087291c311296f6d9ccdf5\src\libcore\macros\mod.rs:10:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Use Case

The actual use case I have for this is a patch I want to submit to svd2rust to support its -g option a bit better. The -g option emits a separate file called generic.rs to split the generic code from the peripherals.

Right now the -g option requires a user to manually add something like the following lines to lib.rs (preferably after form has been run :)):

use generic::*;
pub mod generic;

Otherwise compilation will fail with errors like the following:

     error[E0433]: failed to resolve: maybe a missing crate `FieldReader`?
   --> src\port_1_2\p2ifg.rs:111:25
    |
111 |         P2IFG2_R(crate::FieldReader::new(bits))
    |                         ^^^^^^^^^^^ maybe a missing crate `FieldReader`?

My patch would automate adding the above code, but since my patch causes form to panic, I'd rather wait to submit my patch. I could fix this myself (ignore mod declarations without a body), but I wanted to open an issue in case you wanted to override/had a better idea :).

I often use form for large amounts of generated code. Unfortunately, a single crate will only ever use a single compilation unit. This is a problem when that crate holds 100kloc-1000kloc. Specifically I have one that I am working on with just over a million lines generated.

It would be nice to have a flag that would generate a cargo workspace, instead of a single crate with modules. This would allow parallel compilation to speed compile times, and hopefully hold less RAM at any single point in time.

Instead of:

mod_a/mod.rs
mod_b/mod.rs
lib.rs

this would instead create

mod_a/lib.rs
mod_a/Cargo.toml
mod_b/lib.rs
mod_b/Cargo.toml
mod_root/lib.rs
mod_root/Cargo.toml
./Cargo.toml

Where mod_root would be the only crate you would expect to use (all would have to be published, though).

I may attempt to implement this, but I wanted to open an issue to see if you would be interested in supporting two different modes.

I think you bumped the version locally and published, but forgot to push?

In README.md:

It's advised (but not necessary) to use scalafmt afterwards.

😄

Rust now supports easier module path structure.

Already works on stable.

Details: GHSA-g98v-hv3f-hcfr

Looks like env_logger 0.10.0 changed atty to is-terminal.

This issue triggers Dependabot security warnings.

I faced the problem trying to call form from build.rs when I already have the content in the memory, but as a structure member I don't want to move out nor clone().

PR is on it's way.