These more closely mirror how enums work currently with the macros.
Non-exhaustive enums may be useful though and kind of were the natural
thing to implement.
We can do this because we know that `x < y` cannot create a
`TextCodec<T>` for any `T`. This is because `<` is guaranteed to return
a boolean value, and we simply don't implement `TextCodec<T>` on bool.
This allows stateful or configurable codecs without having to express
all configuration in the type name itself. For example, we could have a
Base64 type with configurable Base64 engines without having to duplicate
the Base64 type itself.
(Note that the different engines in the Base64 crate are values, not
types.)
By removing that, the lint won't trigger for identifiers with trailing
underscores (which become then embedded underscores which normally trips
the `non_camel_case_types` lint).
In 1265f4b, we introduced a change which may cause a conflict of type
names when deriving the traits on two different types. While a
workaround existed (use `mod`s to isolate the implementation), that is
ugly.
This commit allows overriding the choice of type names.
The API changed here, URI became Uri to be more in line with the coding
style.
Also we don’t attempt to trim them any more because that was only used
in the examples, and nowhere in the text of the specification did it say
that those had to be trimmed.
Let’s continue reexporting jid and minidom, but not their inner pub
items, users of this crate can go one level deeper if they need that.
Only xso::error::Error is still useful to reexport, as this is part of
the public API of all of our parsers.
Paths are already patched in the workspace's [patch.crates-io] block.
Not sure why this was added in the first place.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This depends on XEP-0313 for its MAM metadata, and many others such as
XEP-0198, XEP-0280 and XEP-0352 for the inline features, but we
currently provide those as minidom Elements instead.
Text codecs allow to customize the conversion of data from/to XML,
in particular in two scenarios:
1. When the type for which the behaviour is to be defined comes from a
foreign crate, preventing the implementation of
FromXmlText/IntoXmlText.
2. When there is not one obvious, or more than one sensible, way to
convert a value to XML text and back.
This specification defines a token-based method to streamline
authentication in XMPP, allowing fully authenticated stream
establishment within a single round-trip.
This is more in line with how we handle closely coupled specifications
already. While there are subdirectories for "large" specifications (such
as MUC and PubSub), those only refer to a single XEP document. When
there are multiple separate XEP documents, we have separate modules for
that.
There is at least one branch of the FromStr implementation which passes
user input right into the error struct, so we cannot assume that `'` is
not part of that value.
The previous code didn't build with 1.78:
```
error[E0716]: temporary value dropped while borrowed
--> parsers/src/data_forms/validate.rs:394:46
|
380 | let value = match self {
| ----- borrow later stored here
...
394 | Datatype::UserDefined(value) => &format!("x:{value}"),
| ^^^^^^^^^^^^^^^^^^^-
| | |
| | temporary value is freed at the end of this statement
| creates a temporary value which is freed while still in use
|
= note: consider using a `let` binding to create a longer lived value
= note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0716]: temporary value dropped while borrowed
--> parsers/src/data_forms/validate.rs:395:51
|
380 | let value = match self {
| ----- borrow later stored here
...
395 | Datatype::Other { prefix, value } => &format!("{prefix}:{value}"),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^-
| | |
| | temporary value is freed at the end of this statement
| creates a temporary value which is freed while still in use
|
= note: consider using a `let` binding to create a longer lived value
= note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0716`.
```
This seems like a silly reason to pull up the compiler version
requirements, so I fixed it with a trivial modification.
This is bare-bones and is missing many features which we intend to add
in future commits, such as parsing from attributes whose names differ
from the field names and parsing into non-String types.
Well, not really, of course. All of this will make sense once we start
adding support for fields and non-struct types. Refactoring the code now
before we start to add actual member field parsing is much easier.
How do I know that this will work out? Well, my crystal ball knows it.
Don't believe me? Okay, ChatGPT told me ... Alright alright, I went
through the entire process of implementing this feature *twice* at this
point and have a pretty good idea of where to draw the abstraction lines
so that everything falls neatly into place. You'll have to trust me on
this one.
(Or, you know, check out old branches in my xmpp-rs repo. That might
work, too. `feature/derive-macro-streaming-full` might be a name to look
for if you dare.)
This is a large change and as such, it needs good motivation. Let me
remind you of the ultimate goal: we want a derive macro which allows us
to FromXml/IntoXml, and that derive macro should be usable from
`xmpp_parsers` and other crates.
For that, any code generated by the derive macro mustn't depend on any
code in the `xmpp_parsers` crate, because you cannot name the crate you
are in portably (`xmpp_parsers::..` wouldn't resolve within
`xmpp_parsers`, and `crate::..` would point at other crates if the macro
was used in other crates).
We also want to interoperate with code already implementing
`TryFrom<Element>` and `Into<Element>` on structs. This ultimately
requires that we have an error type which is shared by the two
implementations and that error type must be declared in the `xso` crate
to be usable by the macros.
Thus, we port the error type over to use the type declared in `xso`.
This changes the structure of the error type greatly; I do not think
that `xso` should have to know about all the different types we are
parsing there and they don't deserve special treatment. Wrapping them in
a `Box<dyn ..>` seems more appropriate.
