This causes issues in crates using it because they need to have "jid"
listed as a direct dependency when it's not always obvious (version
mismatch etc. when something already uses jid as a dep)
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
When the required child was added and subsequently reverted, it was
noted that optional and required were never defined, and only appeared
in old XEP-0198 examples. The XEP has been fixed already[1].
This basically reverts 0f0759b207.
[1] https://github.com/xsf/xeps/pull/1447
That way, callers can put multiple candidate implementations in, for
example, a sorted vector and more efficiently select candidates to try
when looking at a new element.
That way, we don't need to know the specific type of iterator or even
iteree anymore. This can turn out useful when working with `Box<dyn _>`,
that is, in contexts where we don't know the (possible or actual) types
at compile time.
By removing the implicit `Sized` bound, they can be used with `dyn _`.
The `Sized` bound is unnecessary for a boxed value, so it is a
superfluous restriction. Also, the use with `dyn _` may turn out useful
in the future when we want to allow type-erased XSOs.
Before this, a stream error would not be readable by user code, as the
`recv_features()` function would not even attempt to parse it. This
change allows application code to react to stream errors which are
received before stream features are received.
skip-changelog, because there's no release with the xmlstream module
yet.
This was forgotten in 0f0759b207.
That element is only specified in the XML schema, its semantics aren’t
defined anywhere, but we can guess them anyway.
The only missing check is that #[xml(element)] doesn’t support filtering
on elements with a specific name yet.
skip-changelog: This isn’t a user-visible change.
Stop parsing xml:lang manually, instead use the #[xml(lang)] meta which
tracks it using the XML semantics, inheriting it from the most recent
ancestor.
skip-changelog: This isn’t a user-facing change.
rustc forbids cases where an enum variant and an associated type of a
trait conflict for a while now [1].
We must thus avoid referring to associated items on types we do not
control in the macros. There was only one case I found, and it was in
the TryFrom implementation, and could be easily resolved by explicitly
spelling out Self::Error.
[1]: https://github.com/rust-lang/rust/issues/57644
This provides a clear and consistent interface for selecting TLS-related
features on both (xmpp and tokio-xmpp) crates. All feature checks have
been revamped. All working combinations have been tested (including a
connectivity test + --all-features docs build) using:
```
set -xeuo pipefail
features=(aws_lc_rs ring ktls,aws_lc_rs ktls,ring aws_lc_rs,ring aws_lc_rs,ring,ktls native-tls rustls-any-backend)
export RUSTFLAGS=" -D warnings"
cargo test --no-default-features
cargo test
for feature in ${features[@]}; do
echo ">>> BUILDING with $feature" 2>&1
# Running code or building examples cannot succeed with rustls-any-backend.
features="starttls,$feature"
if [ "$feature" != 'rustls-any-backend' ]; then
if ! cargo test --no-default-features --features="$features"; then
echo ">>> BUILD FAILED for tls feature set: $features" >&2
exit 1
fi
set +e
timeout -sINT -p -k 2 3 cargo run --no-default-features --features="$features" --example keep_connection -- test@hub.sotecware.net "$(pass xmpp/test@hub.sotecware.net)"
status="$?"
set -e
if [ $status -ne 0 ]; then
echo ">>> keep_connection did not shut down cleanly! (status: $status)" >&2
exit 1
fi
else
if ! cargo build --no-default-features --features="$feature"; then
echo ">>> BUILD FAILED for tls feature set: $features" >&2
exit 1
fi
fi
done
RUSTDOCFLAGS="--cfg docsrs" RUSTFLAGS="--cfg xmpprs_doc_build" cargo +nightly doc -Zrustdoc-map --all-features
```
For this, we had to:
- Make the choice(s) of backend explicit in tokio-xmpp features
- Avoid picking a backend through transitive dependencies in xmpp
(reqwest->hyper->rustls).
In addition, we choose the default rustls backend by default and adapt
the examples so that they can cope with either situation.
This way, we don't end up with breakage if rustls is built with more
than one provider enabled. This can (and does) happen if a transitive
dependency (such as reqwest *hinthint*) depends on a specific,
non-default rustls backend.
The user may have to call some global rustls functions depending on the
exact feature set of rustls enabled. Hence, we have to expose it.
Concretely, if the user somehow ends up with more than one rustls
backend, they have to configure one of the backends as default backend
at startup.
The main lib.rs is getting a bit cluttered, so I'm trying to bring some
order into the chaos by moving some things into other modules.
skip-changelog, because there are no user-facing changes (names which
have been moved are doc(inline)'d and pub use'd in the main lib, and
other things (trait implementations) aren't addressable by users).
The stream may have read some data already (such as the stream
header). When initially writing this code, I had missed that we do
actually also carry the parser state over: I misread the
AsyncReader::wrap(..) command as something like AsyncReader::new, i.e.
starting off with fresh parser state, so I assumed that we need a fresh
XmlLangStack, too.
This is wrong: `p` comes from `self.parser.into_inner()` above and is
the parser state, so we need to carry the lang stack along, as well.
This fixes:
```
thread 'tokio-runtime-worker' panicked at […]/rxml-0.13.1/src/xml_lang.rs:87:13:
pop from empty XmlLangStack
```
happening during stream shutdown. The panic was first reported by
@ppjet6, so thanks for that and the keen eye.
skip-changelog, because the bug has not been released yet.
So far this new meta doesn’t work for the BTreeMap<Lang, String>
pattern, which is often used to provide multiple versions of a payload.
skip-changelog: This isn’t a user-facing change.
For codec-based error messages, this reduces the amount of errors per
violation to one. For all others, it improves the placement of the error
slightly, but we still get duplicates.
I couldn't figure out the remaining discrepancies in the spans ...
