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>
allow updates of minor api-macro releases, breaking ones should get
the first or second version tuple bumped anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fixes a regression from commit f50a627f34
which resulted in re-using the prefix without sub-commands when calling
handle_simple_command(_future)
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
since it does no longer store just a userid, but potentially an API
token identifier as well
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
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>
This is similar to what we have in PVE and PMG now. Will be used to
set the real client IP for proxied connections.
with a dummy implementation, which avoids the need to implement it
for the CLI or Backup environments, which do not have or care for a
client IP
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We only used this for the privileges for now, and there it's a
nuisance to alter all bit definitions manually if something is added.
This change makes it count the bits up automatically.
Rename the macro to indicate that this is not a generic name map but
a more specific named bit mapping.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by disallowing [] around ipv4 adresses (which is not very common)
we did not use this anywhere, so there should not be any compatibility
problem
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
