They don't appear in the json data structure and therefore
should not be named separately in the schema. Structs with
flattened fields will become an `AllOf` schema instead.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
to be non fatal for better error messages, this way the user
will see the compile error, but we still generate all the
code & schema variables so that one error isn't accompanied
by all the ones resulting from not having the generated code
there at all.
Eg.
error: description not allowed on external type
--> src/api2/access/user.rs:472:22
|
472 | description: "Get API token metadata (with config digest).",
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Was previously also accompanied by
error[E0425]: cannot find value `API_METHOD_READ_TOKEN` in this scope
--> src/api2/access/user.rs:774:11
|
699 | pub fn delete_token(
| ------ similarly named constant `API_METHOD_DELETE_TOKEN` defined here
...
774 | .get(&API_METHOD_READ_TOKEN)
| ^^^^^^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `API_METHOD_DELETE_TOKEN`
The second error was "wrong" and came much later, needlessly
filling the screen if this happened on multiple functions.
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>
Support raw parameter name identifiers (eg. `r#type`)
#[api(
input: {
properties: {
type: {
type: String,
description: "Foo",
},
},
},
)]
fn foo(r#type: String) { code... }
The "r#type" parameter in the fn decl will match the "type"
parameter name in the input property list.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Instead of setting a default value to a const and inside an
.unwrap_or_else closure, lets set it only to the const and reuse that
later in .unwrap_or
To achieve that we move the "unrwap_or" code for param plumbing code generation
a bit later so that we have easy access to the generated const name.
As all this code is related to optional/default-value stuff it does read still
relatively OK with that change, IMO.
This has the advantage of not getting a warning like:
> warning: constant is never used: `API_METHOD_EXAMPLE_FOO_PARAM_DEFAULT_FORCE`
> --> src/api2/node/foo.rs
> |
> XY | force: {
> | ^^^^^
> = note: `#[warn(dead_code)]` on by default
When one has a API endpoint like:
> #[api(
> input: {
> properties: {
> force: {
> type: bool,
> optional: true,
> default: false,
> },
> },
> },
> ...
> )]
> /// Example
> fn example_foo(force: bool) -> Result<(), Error> {
> if force {
> // do something
> }
> Ok(())
> }
It effectively changes the output for optional parameters with a default set
and no Option<T> from
> let p = p.unwrap_or_else(|| #default_value);
to
> let p = p.unwrap_or(#const_name_for_default);
where the "#const_name_for_default" is a pub const with value
"#default_value"
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
after benchmarking (again), i found that doing a simple find instead
of saving the inidices for the ident strings in a hashmap has
no real performance impact (the max list size for the properties
are max ~25 at the moment, so this should not be impacting compile
times much) but it is much simpler
Signed-off-by: Dominik Csapak <d.csapak@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 'properties_' list is sorted by the the literal string of a
fieldname, but we binary-search for the 'ident_str' (which may be
different, since we map '-' to '_' for example)
by creating a hashmap to map from ident to index, we can do a simple
lookup in that case that will work
benchmarks showed no measurable performance difference
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
API_RETURN_* and API_PARAMETER_* schemas are no references
anymore to allow using them as external schemas via the
`"schema"` key inside object schemas inside the `#[api]`
macro.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
While this is a tiny piece of code, having only one output
code consisting of prepared parts is nicer to keep up to
date.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
remove unnecessary types, they were already in the struct
update test to use Option for access description
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
router.permissions(...) -> router.access(...)
to be more consistent with the other builder methods and
struct member names
ApiAccessPermissions -> ApiAccess
shorter, not necessarily with defined permissions, and
gets rid of a singular/plural confusion
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Not sure how we want to actually handle default values yet.
For now we need to figure out what "feels best".
This adds default values as publicly available consts so
they can be accessed from anywhere as
`API_METHOD_<METHOD_NAME>_PARAM_DEFAULT_<PARAM_NAME>`.
This is quite a handful to type, but I'm not sure how to
make this better.
Within the function body we also have the
`api_get_default!(param_name)` macro which is more
convenient, but not available outside the `#[api]` tagged
function.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
When writing an #[api] function, one can now access default
values by parameter name (see test_default_option in
tests/options.rs):
#[api(...)]
pub fn func(value: Option<isize>) {
println!(
"value: {}",
value.unwrap_or(api_get_default!("value")),
);
}
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
`collect()` uses `FromIterator` which is also implemented
for `Result<Vec, Err>` from `Result<Item, Err>` doing the
same thing.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
(we're not running into this, but ran into an unreachable in
`syn` during development, and I needed to make sure it's not
one of ours...)
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Don't assume an empty object schema for all cases as
newtypes shouldn't use an object schema at all actually!
Signed-off-by: Wolfgang Bumiller <w.bumiller@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>
- handle doc comments for descriptions
- infer fields from structs when possible
- perform some basic error checking
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Adapted from the integer schema, uses f64 type.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Wolfgang Bumiller <w.bumiller@proxmox.com>
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>
