I was really hoping I could contribute faster, but I need to do some studying first :sweat_smile:
Been quite busy this last week with my masters, but will come back ASAP :)
Hey @ordian , I have a WIP. I added a t! test. My test is failing because serde is serializing a more verbose string for the toml document than the json one but they seem to be equivalent. Do you have any advice? https://github.com/ironyman/toml_edit/blob/master/tests/test_valid.rs#L382
thread 'test_dotted_key' panicked at 'assertion failed: `(left == right)`
Diff < left / right > :
Object(
{
< "name": String(
< "Orange",
> "name": Object(
> {
> "type": String(
> "string",
> ),
> "value": String(
> "Orange",
> ),
> },
because value is the the rhs of the = and dotted key is on lhs/
?
Also see https://github.com/toml-lang/toml/issues/499#issuecomment-502408935 on what is allowed/disallowed with multiple dotted keys definitions.
the remaining failures are caused by me misunderstanding what Key.raw means I think
basically I was trying to get add dotted key to work, to do that I had to make the key parser parse dotted keys
which by the way made the key_path parser a wrapper around the key parser
and I changed struct Key to this
#[derive(Debug, Eq, PartialEq, PartialOrd, Ord, Hash, Clone)]
pub struct KeyComp {
// Repr.raw_value have things like single quotes.
repr: Repr,
key: InternalString,
}
#[derive(Debug, Eq, PartialEq, PartialOrd, Ord, Hash, Clone)]
pub struct Key {
pub(crate) comp: Vec<KeyComp>,
raw: InternalString,
}
I'll fix the comp visibility later
Key.keyis a rust string corresponding to the key, so that we can make a lookup on a table, independent of the it's representation in toml, e.g. toml "\t key" and ' key' have the same "rust" key representation, but differ in raw field.
Does that make sense?
The PR you submitted looks in the right direction btw.
Hi! @ordian re. issue #217 in cargo-edit about retaining the predominant string style, my understanding is that the toml output is generated in toml_edit::Document. to_string_in_original_order, correct ? So, cargo-edit doesn’t much control over the output.
It parses the rust string and if it doesn't have quotes, it uses the default
" double quotes. So you can create e.g. value("'0.2'"), see this method.
the first method would break x[“a”][“b”][“c”]
and the second method breaks to_string and sorting by key
Any help
Off this project too since it's part of the cargo-edit
I am that friend ^. We saw the two open issues in
toml_edit and we were planning on reading through the toml v0.5 spec and figuring out what needs to be changed in toml_edit to support all of the v0.5 spec. If anyone could point us to a specific part of the spec we need to add support for to help us get started faster, that would be much appreciated
hey @SamedhG and @thomasharmon808 !Thank you for your interest in helping out with cargo-edit and toml-edit. Regarding toml v0.5, here is the list for things that were added to toml-rs: alexcrichton/toml-rs#224 (it's probably not an exhaustive list). Support for hex/octal/bin literals was already added in ordian/toml_edit#70, and dotted keys are being worked on in ordian/toml_edit#72.
^ Seems to be a complete list of all the changes from 0.4 to 0.5, we could probably start working on support for Inf and Nan over the weekend.
I would also like cargo add to work :)
I don't think there's anywhere else to put the marker for the dotted key
@ironyman I'm not sure either yet. I mean it's possible in theory to make
Item as struct with a private enum field. On the other hand, I'm not yet convinced dotted key should be part of the Item, since the former conceptually represents a key (to the left of =) and the latter is meant for the value (rhs). If I knew what to put where exactly, I would've probably implemented this myself already :) The problem is, I don't have much free time nowadays, but, hopefully, someday I'll manage my time more efficiently :)