Support multiple schemas

[vhdirk]

This PR adds initial support for multiple schemas in a single gschema file.
It's pretty basic and there's probably a lot of caveats, for instance:

• reusing flags/enums will cause these to be generated twice as aux tokenstream. Having a different key in each schema will make different flag structs/enums, which won't be compatible.

• choices using the same key will not work

Is this something you would be willing to pull in?

Edit: I have some ideas to fix this fix the possible issues regarding flags and enums. I propose to to that in an additional PR to keep changesets small.

[SeaDve]

Thanks for the PR! I did a quick review, but I'll do a full review next week, after my finals.

[SeaDve]

reusing flags/enums will cause these to be generated twice as aux tokenstream. Having a different key in each schema will make different flag structs/enums, which won't be compatible.

I'd like to have this fixed first before merging the MR.

choices using the same key will not work

Not sure what you meant by that

Ah, I now get what you meant. Some possible solutions I can think of are:
a. Namespace the enums (adding a prefix or moving it to a module), or;
b. Let the user handle it by suggesting to put each settings struct in their own module (add a useful error message).

[SeaDve]

I think having one of each key for each child schema would be enough for testing

[vhdirk]

I've updated my PR so that it now promotes flags and enums to be standalone, decoupling them from individual schemas.
Since I haven't found any other (simple) way to do this, I've added a 'globals' attribute to the macro, that indicates whether or not they should be generated

[SeaDve]

Looking good! 👍

Since I haven't found any other (simple) way to do this, I've added a 'globals' attribute to the macro, that indicates whether or not they should be generated

Is there a specifc reason why would the user prefer not to generate globals?

[vhdirk]

Is there a specifc reason why would the user prefer not to generate globals?

Well, yes. Take the enum here for instance.
When generating multiple schemas, there's no way to tell of those global structures have been defined before. proc_macro's do not have the ability to look at previously generated code, and while you can keep a thread_local with information regarding previous invocations, you can't know the context that code was generated in. So, you have to set the flag manually.

The alternative would be to just generate everything in the schema in one go, but I've been working on that and it's quite a bit of work, TBH.

[SeaDve]

Ah, that makes sense indeed.

I wonder if it is worth it to push through something like:

gen_settings! {
    const FILE = "...";

    #[gen_settings(id = "...")]
    pub struct Settings;

    #[gen_settings(id = "...")]
    pub struct AnotherSettings;
}

It is a rough scratch of the API, but I think something like that would be less confusing and less thinking on the user side whether to generate the globals.

[SeaDve]

We can also copy quote_spanned syntax:

gen_settings! {"path/to/schema/file"=> 
    #[gen_settings(id = "...")]
    pub struct Settings;

    #[gen_settings(id = "...")]
    pub struct AnotherSettings;
}

or

#[gen_settings(file = "...")]
#[gen_settings_skip(signature = "(ss)")] // global scope
mod settings {
    #[gen_settings(id = "...")]
    #[gen_settings_skip(signature = "(ss)")] // local scope
    pub struct Settings;

    #[gen_settings(id = "...")]
    pub struct AnotherSettings;
}