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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
otherwise this crate cannot be compiled without nightly as
valgrind_request requires feature(asm)
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>
For a T which is not directly a Body or Response<Body> type
#[api]
fn foo() -> T;
should not require a specific Body type.
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>
make -> make check
make check -> cargo test
make fmt -> cargo fmt --all
make checkfmt -> cargo fmt --all -- --check
...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
