teddriggs/syn-inline-mod

Tool to inline module contents into syn::File instances

syn-inline-mod's Issues

Attributes at the top of files are not brought into the module

We're only bringing items over, and should be bringing items and attrs.

Inlining doesn't work properly with include style macros

See jethrogb/rust-reduce#8

Investigate preserving comments

This seems highly desirable for cargo crev's use case.

From each syn::ItemMod that gets parsed, you can find the Span of the semicolon and use Span::start from proc-macro2's "span-locations" feature to figure out the input file line and column of the semicolon. Then you can replace that semicolon character in the original source string with a set of braces containing an indented content of the child module. The final output would be a string of source code rather than syn::File, which the caller can parse to syn::File if they want.

Don't panic on file read/open/parse errors

Looks like this code currently panics if there's an error while the file's being opened, read or parsed: https://github.com/TedDriggs/syn-inline-mod/blob/master/src/resolver.rs#L22-L27

As a library, syn-inline-mod should probably return errors for consumers to process as they wish instead.

Different syn versions

   = note: expected type `&syn::file::File` (struct `syn::file::File`)
              found type `&syn::file::File` (struct `syn::file::File`)
note: Perhaps two different versions of crate `syn` are being used?
  --> src/main.rs:38:39
   |
38 |     let functions = get_syn_functions(&syntax);

This is a snippet from the error i get when I want to get an entire syn-parsed file using syn-inline-mod.

Maybe this crate could be split into just doing the inline part and returning an entire inlined source code. Allowing one to use their own version of syn with the feature flags that I need.

And having the parsing part separate?

update synt, proc-macro2 & quote dependencies

rust-reduce took a dependency on this crate and I'm running into an error running it jethrogb/rust-reduce#5. I think upgrading the dependencies would help.

syn-inline-mod/Cargo.toml

Lines 12 to 17 in 3704707

	[dependencies]
	syn = { version = "0.15.26", features = ["full", "visit-mut"] }
	proc-macro2 = { version = "0.4", features = ["span-locations"] }
	[dev-dependencies]
	quote = "0.6"

The latest are:
https://github.com/dtolnay/syn 1.0.4
https://github.com/alexcrichton/proc-macro2 1.0.6
https://github.com/dtolnay/quote 1.0.2

Preserve source filenames during inlining

Thanks again for releasing version 0.4!

Looks like there's one more thing I need, which is the ability to report errors in the parsed syn::File. For that the main thing I need is to be able to map span data back to the files it came from.

How does this design sound?

• Add an attribute to every inlined file with, say: #[syn_inline_mod_source_path = "..."]. Readers can then look through the attributes (add an API to syn-inline-mod to do so for convenience).
• Add a method to InlinerBuilder which configures whether these annotations should be inserted (default false).

I'm planning to publish a crate that ties together syn-inline-mod and codespan-reporting so that tools can report custom errors.

Missing guide/ example

I am trying to expand Rust code to other languages using Rust_swig, which is using syn.
From what I understand syn-inline-mod can parse Rust code, and it understands #cfg, which syn lacks (dtolnay/syn#588). I am trying to use syn-inline-mod in Rust swig, but I don't fully understand it. Can you include some guide/ example code on how to use it?

Paths in cfg_attr should be honored

Consider the following example from dtolnay/request-for-implementation#6

r#"
#[cfg(feature = "m1")]
mod m1;

#[cfg_attr(feature = "m2", path = "m2.rs")]
#[cfg_attr(not(feature = "m2"), path = "empty.rs")]
mod placeholder;

According to that ticket, this should expand to two declarations of mod placeholder, with the cfg_attr being converted to a normal cfg attribute.

I'm not sure this is worth the complexity it creates. Consider the following case:

#[cfg_attr(feature = "foo", path = "m2")]
#[cfg_attr(not(feature = "foo"), path = "m3")]
mod outer {
    #[cfg_attr(feature = "foo", path = "baz.rs")]
    #[cfg_attr(not(feature = "foo"), path = "bar.rs")]
    mod placeholder;
}

We'd need to emit outer twice, with placeholder twice inside.

Write documentation showing example input and output

I can't tell from the readme and current documentation what this crate does and which edge cases it can/cannot handle.