IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
Objects and arrays are now optionally identified by their
'properties' or 'items' property if their 'type' is left
out.
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>
Otherwise we have .16 and .17 in the same project. And we
can't go to .18 currently until hyper/tokio git-master are
in sync again.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Otherwise we'll get even more errors.
Consider this example:
#[api(...)]
struct Foo { ... }
impl MyTrait for Foo { ... }
If the #[api] macro fails and does not at least produce the
`struct Foo{}` along with its `compile_error!()` output,
then in addition to our macro errors, we'll see errors about
trying to implement `MyTrait` for an unknown thing called
`Foo`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
When deserializing we currently expect all fields to be
available, but we actually want Option types to be truly
optional...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We now derive Serialize and Deserialize automatically.
This way we'll be able to add verifiers right into the
structs, support our 'rename' functionality, and our
'default' handling etc. which needs to be compatible with
what we have in perl.
Ideally this will also give us the option to mark structs as
being perl-compatible "property strings"
(PVE::JSONSchema::parse_property_string()) and automatically
derive FromStr for structs on demand.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
In PVE we have multiple different enum types: hyphenated,
all-caps, underscores.
By default our api-macro enums will convert CamelCase to
underscores, so we need a way to represent the rest:
enum AnEnum {
CaseOne, // becomes "case_one",
#[api(rename = "case-two")]
CaseTwo, // "case-two",
#[api(rename = "CASE_THREE")]
CaseThree,
}
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Move the Name type into types.rs and make it hashable.
Expression::Object not contains an Object where the
hashmap's key is a Name and therefore preserves the Span of
all the keys for better error messages.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The method info part is not generic after all.
(Makes it easier to test different representations of
ApiHandler without having to adapt all the other methods as
well.)
Signed-off-by: Wolfgang Bumiller <wry.git@bumiller.com>
An `fn` type can be more annoying to produce in some generic
cases, and we haven't really needed it yet.
Signed-off-by: Wolfgang Bumiller <wry.git@bumiller.com>
This way we do not need to carry the body type into the CLI
router and can instead just require the body to be
Into<Bytes>.
This also makes more sense, because previously a method
could in theory implement multiple ApiMethodInfo types with
different bodies which seems pointless.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Drop #!feature(specialization) in favor of having a `cli`
property for types to decide whether they are CLI
compatible.
The unconstrained_type! macro now has both ParseCli and
ParseCliFromStr in view, and requires one of the two to be
implemented for a type. This means that if a type implements
FromStr, it should "just work".
For types created without the help of the #[api] macro,
there's a shortcut to exclude a type from the CLI via
the no_cli_type!{typename} macro.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
In order to get parameters from the command line into the
API we need to get them into a json value, so that we can
pass it down the handler which deserializes them into their
real type and runs verifications.
For this we need to define how the type is going to be
converted into a json Value. We cannot simply use
Deserialize as that would for instance require quotes
around strings. So instead, we have a ParseCli trait, which
is a nop (direct serde_json::Value::String()) for string
types, and uses .parse() (the std::str::FromStr trait) for
everything else.
Currently this uses a `default fn` as an example of the
specialization feature, but I'll probably remove this and
use yet another mass-impl macro since there isn't much
activity on that feature's issue tracker. (The issue itself
seems to be outdated ...
Signed-off-by: Wolfgang Bumiller <wry.git@bumiller.com>
while filling the Parameter fields as &'static we cannot
really make use of the get_type_info() yet because it would
need to be a `const fn` (possible via #!feature(const_fn)),
so for now we store the method pointer until `const_fn` is
stable
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This should support arbitrary expresion, so gobble up
elements up to the next comma and then run it through
syn::parse2.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
TODO:
- change parse_object to use Punctuated for the fields to
support longer value types (so we can use actual types
as fields)
- allow adding a body type to methods
- allow adding a body type to routers explicitly
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
