Commit graph xmpp-rs/xso-proc/src/field/attribute.rs
Author SHA1 Message Date
Jonas Schäfer
de39f410d5 xso-proc: improve spans for error messages
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 ...
2025-05-02 17:16:59 +02:00
Jonas Schäfer
67f3ffaced xso: re-implement #[xml(lang)] on top of #[xml(attribute)]
This gives us all the goodies of `default`, `type_` and `codec` without
having to duplicate lots of code (and I think the `match`-iness of the
new macro code is still within limits).

However, we still keep them as separate `#[xml(..)]` attributes, because
their semantics are very different and it is sensible to make them stand
out.

skip-changelog, because `#[xml(lang)]` was introduced in this version.
2025-04-27 14:19:31 +02:00
Jonas Schäfer
9fdb1564f6 xso: reject attempts to match the same XML attribute in different fields
This was a bit tricky to build, because it is possible to have an
indirection through a `static` there. Thanks to Rust's extensive
const-fn capabilities, though, it's in fact possible to cover all cases.

We still do two different checks to improve user experience. If we can,
from within the proc macro, determine that two fields refer to the same
XML attribute (because their namespace/name values use the same Rust
tokens), then we reject the fields with a clear error message pointing
at both fields.

In the other case, when there's e.g. `#[xml(lang)]` and
`#[xml(attribute(namespace = rxml::XMLNS_XML, name = "lang"))]`, the
macro cannot be sure that XMLNS_XML is in fact the XML namespace. For
that case, we generate code which is evaluated at compile time (and
has no runtime impact) which panics if the namespace and name of two
attribute-matching fields is the same.

The error message will be less clear (because it contains extra,
unchangeable wording like "evaluation of constant value failed" and "the
evaluated program panicked at", which may be a bit confusing) than the
message generated by the macros themselves, but it's a price we have to
pay unfortunately.

Note that this check may seem cosmetic and purely for better user
experience, but it is in fact needed to avoid generating not-well-formed
and/or not-namespace-well-formed XML: As `AsXml` generates `xso::Item`,
where each attribute is emitted separated (and not aggregated in a
map structure), a naive (and efficient) implementation of a writer might
not double-check that no duplicate attributes are generated.
2025-04-27 11:18:50 +02:00
Jonas Schäfer
beae4ae66b xso: fix no_std support
This reverts the Revert in 6ec275d3 which had to be done in order to
un-break usage of xso in std crates.
2025-01-26 15:07:17 +00:00
Emmanuel Gil Peyrot
01a0c51a2f xso-proc: Add support for the codec field on attribute meta
This allows a custom TextCodec to be used for encoding and decoding the
attribute’s value, instead of FromXmlText and AsOptionalXmlText.
2025-01-25 18:07:44 +01:00
Jonas Schäfer
6ec275d381 Revert "xso-proc: Replace std stuff with alloc/core stuff"
This reverts commit 4e5f0bc961.

Unfortunately, in std contexts, the `alloc` crate is not imported. That
means we cannot rely on it being accessible and it in fact breaks builds
of crates which are not `no_std`.

Fixes #155.
2025-01-20 17:52:35 +01:00
4e5f0bc961 xso-proc: Replace std stuff with alloc/core stuff 2024-12-19 20:51:56 +01:00
Jonas Schäfer
2358c8636e xso-proc: refactor field implementations into separate files
This decreases indentation levels on the various implemenations, it
groups the implementations together physically, and (spoiler alert!)
we'll actually need the dyn Field trait object-ness (much) later on.
2024-08-04 16:14:47 +02:00