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>
