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.
Jonas Schäfer
created
46584f0
xso: refine handling of multiple `#[xml(text)]` fields
Click to expand commit body
Previously, we only enforced the existence of at most one `#[xml(text)]`
field only at code generation time for `FromXml`. This change enforces
it at parsing time, which is more consistent and allows for a clearer
error message.
Jonas Schäfer
created
ae30221
xso: only fail on non-whitespace unknown text
Click to expand commit body
We hereby ignore whitespace-only unexpected text, because that's
generally harmless.
298bf00
parsers: use derive macros for simple text-based elements
Jonas Schäfer
created
b0803f8
xso-proc: add support for parsing text content
Jonas Schäfer
created
92e69cf
xso-proc: add debug mode for development purposes
Jonas Schäfer
created
32e8f2e
xmpp-parsers: Implement XEP-0484: Fast Authentication Streamlining Tokens
Click to expand commit body
This specification defines a token-based method to streamline
authentication in XMPP, allowing fully authenticated stream
establishment within a single round-trip.
Emmanuel Gil Peyrot
created
972a842
xmpp-parsers: Use the new macro for the feature element
Emmanuel Gil Peyrot
created
0e48650
parsers: port more elements to derive macros
e439e99
parsers: port more generate_element! usages to derive macros
Jonas Schäfer
created
0c57be3
xso-proc: add support for defaulting in attribute parsing
Jonas Schäfer
created
cea246a
parsers: port more generate_element! usages to derive macros
Jonas Schäfer
created
4e9c488
parsers: add xso text trait implementations to types
Click to expand commit body
This allows them to be used as attribute in xso-proc derived structs.
Jonas Schäfer
created
c0fc7f4
xso-proc: add support for non-String typed attributes
Jonas Schäfer
created
1f679c3
xso: add traits for XML text <-> value conversion
Click to expand commit body
The traits have undergone a couple iterations and this is what we end up
with. The core issue which makes this entire thing ugly is the
Orphan Rule, preventing some trait implementations relating to types
which haven't been defined in this crate.
In an ideal world, we would implement FromXmlText and IntoXmlText for
all types implementing FromStr and/or fmt::Display.
This comes with two severe issues:
1. Downstream crates cannot chose to have different
parsing/serialisation behaviour for "normal" text vs. xml.
2. We ourselves cannot define a behaviour for `Option<T>`. `Option<T>`
does not implement `FromStr` (nor `Display`), but the standard
library *could* do that at some point, and thus Rust doesn't let us
implement e.g. `FromXmlText for Option<T> where T: FromXmlText`,
if we also implement it on `T: FromStr`.
The second one hurts particularly once we get to optional attributes:
For these, we need to "detect" that the type is in fact `Option<T>`,
because we then need to invoke `FromXmlText` on `T` instead of
`Option<T>`. Unfortunately, we cannot do that: macros operate on token
streams and we have no type information available.
We can of course match on the name `Option`, but that breaks down when
users re-import `Option` under a different name. Even just enumerating
all the possible correct ways of using `Option` from the standard
library (there are more than three) would be a nuisance at best.
Hence, we need *another* trait or at least a specialized implementation
of `FromXmlText for Option<T>`, and we cannot do that if we blanket-impl
`FromXmlText` on `T: FromStr`.
That makes the traits what they are, and introduces the requirement that
we know about any upstream crate which anyone might want to parse from
or to XML. This sucks a lot, but that's the state of the world. We are
late to the party, and we cannot expect everyone to do the same they
have done for `serde` (many crates have a `feature = "serde"` which then
provides Serialize/Deserialize trait impls for their types).
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.
cb09ab8
parsers: use built-in string quoting instead of manual quoting
Click to expand commit body
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.
Jonas Schäfer
created
6ade419
xso-proc: improve combinatorial test coverage for attribute fields
Click to expand commit body
This is to avoid another regression slip through the test suite, as had
happened in d4d520e (fixed in this commit's parent).
Jonas Schäfer
created
c0d109d
xso-proc: fix renaming attributes using a static item
Click to expand commit body
This was broken by d4d520e by accident, and of course we didn't have
tests for that :-).
(we do, now)
This got introduced in 2e3004f89e77e6f4dd0cc9cb228fb3e5233cd530, but
there should be no reason to run ignored tests; if they are #[ignore]
it’s probably for a good reason.
This is particularly annoying with doctests, where ignore is used to
explicitly highlight broken/untested code.
Thanks jonas’ for noticing!
ffd0c3c
Add support for XEP-0122: Data Forms Validation
mb
created
d4d520e
xso-proc: add support for built-in prefixes in attribute names
Click to expand commit body
This simplifies the use of built-in XML attributes such as xml:lang.
Jonas Schäfer
created
84de7fc
xso-proc: add support for namespaced attributes
Jonas Schäfer
created
219d682
xso-proc: add support for renaming attributes
Click to expand commit body
This is akin to `#[serde(rename = ..)]` and thus useful.
Jonas Schäfer
created
0bae5d3
parsers: replace some generate_element! usage with derive macros
Jonas Schäfer
created
212c5c4
xso-proc: add support for parsing attributes into Strings
Click to expand commit body
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.
Jonas Schäfer
created
183bef5
xso-proc: completely overengineer everything for no good reason!
Click to expand commit body
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.)
If we are going to support structs with fields, it would be good to have
that struct-related code organised a little and less splashed over the
main lib.rs file.