This mostly affected attribute parsing (due to the syn::Meta changes).
Also creating `DelimSpan`s for custom-built `syn::Attribute`s is a
bit... ugly.
Upshot: turns out we can drop some helpers in util.rs with the new
`syn::Meta` changes.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This allows fixing up things such as `skip_serialize_if`
calls like so:
#[derive(Updater)]
struct Foo {
#[serde(skip_serializing_if = "MyType::is_special")]
#[updater(serde(skip_serializing_if = "Option::is_none"))]
field: MyType,
}
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
#[api]
struct Foo {
field: Bar,
}
does not require the use of
#[api(
properties: {
field: {
type: Bar,
},
},
)]
anymore
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
References to external schemas (or types) already include
the description in the external schema and therefore are
illegal.
The implementation consists of multiple parts:
* Introduce a `Maybe` type which can be `Explicit`,
`Derived` or `None`.
* Forbid `Explicit` descriptions on references.
* Instead of bailing out on such errors which causes all of
the generated code to vanish and create heaps of
additional nonsensical errors, add a way to *add* errors
without bailing out immediately via the `error!()` macro.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
by replacing more characters ('.','+') by '_' and prefix them when
it starts with a number
we sometimes need to parse such fields, e.g in serde attributes like
#[serde(rename = "802.3ad")]
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The description comes from the doc comment, the field types
and description from field doc comments and types.
Previously we needed to add at least the hint that the
schema is an object schema. Now we support an empty #[api]
attribute as well.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
infer_type now also returns whether it was encapsualted in
an Option<>. So `type: String, optional: true` is now
inferred propertly from `Option<String>`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The function attribute reader doesn't read any other
attributes anymore, so make it reusable!
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Initially it was a wrapper around Ident to avoid some
copies, but now it's what we use to allow hyphenated names
for fields in objects (as `syn::Ident` doesn't allow that at
all), so give it a more fitting name.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The user must always be explicit about whether the Ident or
the String is required, since they may differ.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
See the test example:
assuming a `pub struct Foo` which implements `Serialize` and
`Deserialize`, we also expect it to provide a
`pub const Foo::API_SCHEMA: &Schema` like so:
#[derive(Deserialize, Serialize)]
pub struct StrongString(String);
impl StrongString {
pub const API_SCHEMA: &'static Schema =
&StringSchema::new("Some generic string")
.format(&ApiStringFormat::Enum(&["a", "b"]))
.schema();
}
Then we can use:
#[api(
input: {
properties: {
arg: { type: StrongString },
}
},
...
)]
fn my_api_func(arg: StrongString) -> Result<...> {
...
}
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We may want to add the ability to declare a Schema for
structs, so factorize function handling into its own file.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The json value type is more of an intermediate step between
the TokenStream and the Schema type and should stay somewhat
independent of it. We may want to reuse it for the router?
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
enum Foo {
Variant1(Type), // allowed
Variant2(Type, Type), // not allowed
Variant3 { name: Type }, // not allowed
}
In the simple case of a single type we simply drop the
automatically derived `FromStr`/`Display` impls and expect
the user to implement them manually, while in the `verify()`
method we simply match on self and forward to the inner
verifier.
So to get "tagged unions" in the API, implement a proper
API type for each variant, then add an enum with 1-tuple
variants.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
