This fixes the reStructuredText (ReST) output for more complex formats
where we got, for example, a definition list of all properties of a
(section) configuration with one or more properties then having a
sub-format that is also rendered as a list.
Such nested lists are possible in ReST but need to be separated by a
blank line [0].
Without this we got quite a few warnings/errors from the Sphinx/ReST
buildsystem looking like:
> config/datastore/config.rst:19: ERROR: Unexpected indentation.
> config/datastore/config.rst:20: WARNING: Block quote ends without a blank line; unexpected unindent.
[0]: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#lists-and-quote-like-blocks
Reported-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This way we can copy and modify a schema.
Eg. via the following ways:
const FOO_SCHEMA: Schema = SOME_SCHEMA
.unwrap_integer_schema_cloned()
.description("Foo")
.schema();
Note that for example there is currently no builder to set a
`default_key` for an `ObjectSchema` back to None, so one could do:
const FOO_SCHEMA: Schema = const {
let mut schema = SOME_SCHEMA.unwrap_object_schema_cloned();
schema.default_key = None;
schema.schema()
};
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Because the UI kept producing them...
And still does...
This is NOT meant to be used by anything other than generated legacy
code for PDM (pve-api-types) and only affects the serde based
deserializer. The "old" `schema.parse_property_string() -> Value`
method does not utilize this for now.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
so that we can have a property:
```
foo: Option<PropertyString<Bar>>,
```
within a struct that derives `Updater`
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The wrap_text helper accepts and initial indentation, so use that as
central point to add the indentation that glues the list entry
together with its description.
Mostly a small optimization, should not matter in practice, i.e. where
all properties should have a description.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While this is technically a breaking API change since the trait is
public, we don't implement it anywhere and it isn't meant to be
implemented from the outside.
Also, encode that these types are all Send + Sync via a super trait
notation.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Fixes the clippy lint:
warning: bound is defined in more than one place
--> proxmox-schema/src/property_string.rs:352:14
|
352 | pub fn parse<T: ApiType>(value: &str) -> Result<T, Error>
| ^
353 | where
354 | T: for<'de> Deserialize<'de>,
| ^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#multiple_bound_locations
= note: `#[warn(clippy::multiple_bound_locations)]` on by default
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
This is completely wrong and make working with it extremely annoying.
Whether or not there should be separation should be decided where
multiple elements are connected, they shouldn't automatically come
with a bunch of trailing new lines for absolutely no reason.
Places using this will need to be fixed as they get noticed.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Fixes the clippy warning:
warning: initializer for `thread_local` value can be made `const`
--> proxmox-router/src/cli/command.rs:221:71
|
221 | static HELP_CONTEXT: RefCell<Option<Arc<CommandLineInterface>>> = RefCell::new(None);
| ^^^^^^^^^^^^^^^^^^ help: replace with: `const { RefCell::new(None) }`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#thread_local_initializer_can_be_made_const
= note: `#[warn(clippy::thread_local_initializer_can_be_made_const)]` on by default
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Macro rules are not hygienic, and current rust macro visibility rules
are a nightmare. Using const_format::concatcp!() is a much cleaner
solution.
Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
rather than just always allowing additional properties, only return
true if any of the available schemas allows it
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
and reuse splitting code in no_schema's SeqAccess as well
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
A 'oneOf' schema is basically exactly what a rust `enum` is.
Exactly one of the possible values must match the data.
This should ultimately be the base to allow using the
`#[api]` macro on a newtype style enum as well as using this
schema as a configuration for our section config parser.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
