Revised Config

[ambiguousname]

Put config language in tool/config.rs, and it can currently be set through a config.toml file (which can be customized on the command line).

Some TODOs here:

• Shared attributes (like lib_name)
  • Logic in Kotlin for overriding these shared attributes
• Setting config options through the command line
• Setting config options through attributes
  • Revise system to not use inner attributes (we cannot make rustc ignore inner attributes when compiling)
  • Get feedback on the attributes config system (the current version is just to prove that we can hook it up to everything else).
  • Attribute validation for only top-level types
  • Expand to work recursively in submodules?
• Fix demo_gen config
• Automatic override for shared config based on current backend
• Consistent naming pattern (serde(rename_all="kebab-case")?)
• Add tests for parsing (and overrides)
• Documentation

Fixes #772

[ambiguousname]

Main functionality is in, mostly looking for feedback on:

Config struct

We okay with how the struct is set up and how each backend handles accessing it?

Specifically, pay close attention to how there are two lib_name fields, one belonging to SharedConfig and the other to KotlinConfig. There's logic in the kotlin backend to use either SharedConfig or override, and I want to make sure if we're okay having the backend developers handle this kind of overriding logic themselves.

Attribute system

Can't use a custom inner attribute, they're considered unstable at the moment.

Currently planning on a system like:

#[diplomat::config(some.option = yes)]
struct Config;

// Modules can also have config structs:
pub mod some_other_thing;
/* some_other_thing.rs
#[diplomat::config(option.one = 42)]
struct SomeOtherConfig {}
*/

#[diplomat::bridge]
#[diplomat::config(other.options = sure)]
mod ffi {
  // No configs here
}

I think restricting the config attribute to structs at the top-most level helps with clarity and organization of where config attributes are supposed to go. Didn't want to iterate on this too much until I got some feedback on usage.

Merging system

Feels a little convoluted, but I'm not sure there are many better alternatives? Right now we have to convert every Config struct in to toml::value::Table, then BACK into a Config. Every time we convert between types however, it involves converting the struct into bytes and then back from bytes. So it's just a lot of conversion, don't know if I see a way around it though.

[Manishearth]

Mostly shaped correctly, will do in depth review later

[Manishearth]

Thought: these shouldn't be allowed on random types, we should require they go on a toplevel type in lib.rs (with whatever name they get).

[Manishearth]

Can't use a custom inner attribute, they're considered unstable at the moment.

Yeah I think I noted this in the issue.

and I want to make sure if we're okay having the backend developers handle this kind of overriding logic themselves

I would love for the override to be automatic, but I'll look closer at the code.

Feels a little convoluted, but I'm not sure there are many better alternatives?

Tbh not a big deal to have a set_key method that manually passes config values down. I don't think we're going to have tons of these.