↔️ toml-span
Span-preserving toml deserializer
Differences from toml
First off I just want to be up front and clear about the differences/limitations of this crate versus toml
- No
serde
support for deserialization, there is aserde
feature, but that only enables serialization of theValue
andSpanned
types. - No toml serialization. This crate is only intended to be a span preserving deserializer, there is no intention to provide serialization to toml, especially the advanced format preserving kind provided by
toml-edit
. - No datetime deserialization. It would be trivial to add support for this (behind an optional feature), I just have no use for it at the moment. PRs welcome.
Why does this crate exist?
The problem
This crate was specifically made to suit the needs of cargo-deny, namely, that it can always retrieve the span of any toml item that it wants to. While the toml crate can also produce span information via toml::Spanned there is one rather significant limitation, namely, that it must pass through serde. While in simple cases the Spanned
type works quite well, eg.
As soon as you have a more complicated scenario, the mechanism that toml
uses to get the span information breaks down.
thread 'main' panicked at src/main.rs:20:45:
failed to deserialize toml: Error { inner: Error { inner: TomlError { message: "data did not match any variant of untagged enum Ohno", original: Some("\ninteger = 42\nstring = \"we want this to be spanned\"\n"), keys: ["string"], span: Some(23..51) } } }
To understand why this fails we can look at what #[derive(serde::Deserialize)]
expand to for Ohno
in HIR.
extern crate serde as _serde;
What serde does in the untagged case is first deserialize into _serde::__private::de::Content
, an internal API container that is easiest to think of as something like serde_json::Value
. This is because serde speculatively parses each enum variant until one succeeds by passing a ContentRefDeserializer
that just borrows the deserialized Content
from earlier to satisfy the serde deserialize API consuming the Deserializer
. The problem comes because of how toml::Spanned
works, namely that it uses a hack to workaround the limitations of the serde API in order to "deserialize" the item as well as its span information, by the Spanned
object specifically requesting a set of keys from the toml::Deserializer
impl so that it can encode the span information as if it was a struct to satisfy serde. But serde doesn't know that when it deserializes the Content
object, it just knows that the Deserializer reports it has a string, int or what have you, and deserializes that, "losing" the span information. This problem also affects things like #[serde(flatten)]
for slightly different reasons, but they all basically come down to the serde API not truly supporting span information, nor any plans to.
How toml-span
is different
This crate works by just...not using serde
. The core of the crate is based off of basic-toml which itself a fork of toml v0.5
before it added a ton of features an complexity that...well, is not needed by cargo-deny or many other crates that only need deserialization.
Removing serde
support means that while deserialization must be manually written, which can be tedious in some cases, while doing the porting of cargo-deny I actually came to appreciate it more and more due to a couple of things.
- Maximal control.
toml-span
does an initial deserialization pass intotoml_span::value::Value
which keeps span information for both keys and values, and provides helpers (namelyTableHelper
), but other than satisfying thetoml_span::Deserialize
trait doesn't restrict you in how you want to deserialize your values, and you don't even have to use that if you don't want to. - While it's slower to manually write deserialization code rather than just putting on a few serde attributes, the truth is that that initial convenience carries a compile time cost in terms of
serde_derive
and all of its dependencies, as well as all of the code that is generated, for...ever. This is fine when you are prototyping, but becomes quite wasteful once you have (mostly/somewhat) stabilized your data format. - (optional) Span-based errors.
toml-span
provides thereporting
feature that can be enabled to havetoml_span::Error
be able to be converted into a Diagnostic which can provide nice error output if you use thecodespan-reporting
crate.
Usage
Simple
The most simple use case for toml-span
is just as slimmer version of toml
that also has a pointer API similar to serde_json allowing easy piecemeal deserialization of a toml document.
toml
version
toml-span
version
Common
Of course the most common case is deserializing toml into Rust containers.
toml
version
toml-span
version
The following code is much more verbose (before proc macros run at least), but show cases something that moving cargo-deny to toml-span
allowed, namely, PackageSpec
.
Before toml-span
, all cases where a user specifies a crate spec, (ie, name + optional version requirement) was done via two separate fields, name
and version
. This was quite verbose, as in many cases not only is version
not specified, but also could be just a string if the user doesn't need/want to provide other fields. Normally one would use the string or struct idiom but this was impossible due to how I wanted to reorganize the data to have the package spec as either a string or struct, as well as optional data that is flattened to the same level as the package spec. But since toml-span
changes how deserialization is done, this change was quite trivial after the initial work of getting the crate stood up was done.
pub type CrateBan = ;
Contributing
We welcome community contributions to this project.
Please read our Contributor Guide for more information on how to get started. Please also read our Contributor Terms before you make any contributions.
Any contribution intentionally submitted for inclusion in an Embark Studios project, shall comply with the Rust standard licensing model (MIT OR Apache 2.0) and therefore be dual licensed as described below, without any additional terms or conditions:
License
This contribution is dual licensed under EITHER OF
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
For clarity, "your" refers to Embark or any other licensee/user of the contribution.