test code that is a library instead of a bin

[TomzBench]

hello,

i am using this library to test generated code but not via proc macros. just a library that outputs regular rust. My generated code is a library (therefore, no fn main() {}). My tests fail unless i stub in a fn main() {} somewhere to my generated code. but this is not ideal. For clearer picture, below is an example test case...

#[test]
fn test_render_lib() {
    let runner = trybuild::TestCases::new();
    render_lib("__generated__/default.rs", Options::default());
    runner.pass("__generated__/default.rs");
}

So you see, I do not write my actual files that I am testing, but I generate them. And rust is compiling this generated code as a binary. Is there a way to make the test case compile as a library?

[dtolnay]

I would prefer not to support this in this library.

[nyurik]

I ran into the same issue - any code generator has exactly the same problem. At the moment, we are forced to add fn main() {} to the output just so that we can use trybuild. Also, I use insta (in binary mode) to generate the .rs files so that I am certain the generated results do not change accidentally - and I point trybuild to those filse.

[TomzBench]

I ended up doing a more rust native code Gen approach with proc macros anyway. Probably why he doesn't want to support this use case. It's not the "rust" way to do it. And stubing in a main function wasn't to bad for code Gen the external way.

[nyurik]

I think this is an issue of "who is the driver".

• In a more common scenario, a test case is the driver: you have a small file with a main() that calls a macro with all the custom parameters.
• In a less common scenario like mine, I have many test files (DBC - arcane serialization definition files). The actual test case is a boilerplate that uses each DBC file one by one. Which means the DBC files are the driver, and adding another DBC file should automatically do the whole testing chain - generate the code (storing the snapshot to ensure stability) and compile it.

[TomzBench]

from your readme, it looks like your generating code in a build script. but the "rust way" (for better or worse!) is something like

dbc_codegen::generate!("path/to/file.dbc");

Is your way better, easier on the eyes, better to inspect w/o cargo-expand and brittle rust analyzer? probably! :)

is it the "rust way"? probably not - but maybe could be?!?

[TomzBench]

if its any consolidation, i was doing something very similar when i ran into the issue. But instead of can bus, i did code gen from CDDL (conside data definition format) - to develop encoders/decoders for CBOR formats.

I went from string based template generation to the quote crate, which was pretty great experience. w/ quote, your codegen becomes almost like writing rust code w/ template params. its great. but probably a big re-write for your codegen.

what you give up w/ snap shots and normal files, in return you get nice template engine for rust code. its your call! but the maintainer also maintains the quote crate. and my guess he will nudge you into the macro direction.

[nyurik]

quote! migration a work in progress (wasn't me who wrote the original), and sadly it is significantly longer than writeln!. I have been looking at https://github.com/yasuo-ozu/template_quote to extend quote into more like a generic templating language, but it seems that project is not actively maintained.

Getting back to the topic though, using build.rs or dbc_codegen::generate! is not that much different. The goal here is NOT to duplicate things. Even with the generate! approach, I cannot do what trybuild offers: pass("..../*.dbc") -- ability to do wildcards on a set of files, avoiding the need to have TWO files for each test case - one .dbc and one hand-written .rs with a main function.

[TomzBench]

ahhh, wildcard drop in test cases. cool. this limitation defintly pukes up your cool test flow. so your codegen probably has some "if test, inject main" logic. 🤮

+1 - goodluck!