Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 30 17:44
    steviez closed #351
  • Sep 30 17:44
    steviez commented #351
  • Sep 30 00:25
    epage commented #351
  • Sep 29 23:24
    steviez opened #351
  • Sep 29 12:48
    mitsuhiko commented #346
  • Sep 27 14:11
    WhyNotHugo synchronize #349
  • Sep 27 14:10
    WhyNotHugo synchronize #349
  • Sep 27 06:58
    Kixunil commented #346
  • Sep 26 18:41
    epage commented #346
  • Sep 26 18:40
    epage edited #340
  • Sep 26 15:03
    epage edited #349
  • Sep 26 15:00
    epage closed #350
  • Sep 26 15:00

    epage on main

    refactor: Remove use of `extern… Merge pull request #350 from ep… (compare)

  • Sep 26 14:48
    epage synchronize #350
  • Sep 26 14:48

    epage on main

    fix(fuzz): Unbreak tests (compare)

  • Sep 26 14:41
    epage opened #350
  • Sep 26 14:34

    epage on main

    refactor(fuzz): Avoid breaking … (compare)

  • Sep 26 13:26
    WhyNotHugo opened #349
  • Sep 24 16:58

    ordian on main

    fix: Fuzz build error (#348) T… (compare)

  • Sep 24 16:58
    ordian closed #348
ironyman
@ironyman
because value is the the rhs of the = and dotted key is on lhs/
?
Andronik Ordian
@ordian
@ironyman Ah, yes, you're right. It seems like we need to generalize the key type (lhs) to be an enum. Not sure if that's the most obvious and ergonomic way to implement dotted keys though.
Andronik Ordian
@ordian
Also see https://github.com/toml-lang/toml/issues/499#issuecomment-502408935 on what is allowed/disallowed with multiple dotted keys definitions.
ironyman
@ironyman
I'm trying to make key parser parse into Vec<Key> and it's breaking everything :|
Andronik Ordian
@ordian
@ironyman hey, thanks for reaching out, I'll try to reserve some time this week to help overcoming the difficulties
ironyman
@ironyman
I managed to fix most of the test failures
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
Andronik Ordian
@ordian
@ironyman hey, so regarding Key.raw
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?
Andronik Ordian
@ordian
Let me know if there is anything I can help you with.
The PR you submitted looks in the right direction btw.
Steve Degosserie
@stiiifff
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.
Andronik Ordian
@ordian
@stiiifff hey, not exactly. Document::to_string just serializes whatever it has in the internal representation to a string. We set the string values here and there. They both accept a generic argument Into<Value>, which is implemented here for a string.
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.
Steve Degosserie
@stiiifff
Awesome thanks 🙏 will look into it.
ironyman
@ironyman
@ordian right now, I can’t decide between putting the key a.b.c in x = { a.b.c = .... } into table x’s KeyValuePairs or creating sub tables for a, b in x then putting c in table b’s KeyValuePairs
the first method would break x[“a”][“b”][“c”]
and the second method breaks to_string and sorting by key
Andronik Ordian
@ordian
@ironyman hmm, it seems like dotted keys don't play nicely with our structured API, let me think this through and come back to you with ideas
SamedhG
@SamedhG
Hey, My friend and I was interested in helping out with the Cargo-edit project and would love to see if you guys need
Any help
Off this project too since it's part of the cargo-edit
Thomas Harmon
@goodSyntax808
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
Andronik Ordian
@ordian
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.
Andronik Ordian
@ordian
:+1:
ironyman
@ironyman
@ordian any ideas on how we should proceed?
I would also like cargo add to work :)
Andronik Ordian
@ordian
@ironyman sflr, I think dotted keys should be handled similar to inline tables, but have an implicit field similar to tables, added a comment to #72. So it should be possible to add a new type DottedKey to Value.
ironyman
@ironyman
Andronik Ordian
@ordian
@ironyman thanks, I'll take a look today
ironyman
@ironyman
@ordian I'm not sure how we should address the last comment on enum Item
I don't think there's anywhere else to put the marker for the dotted key
Andronik Ordian
@ordian
@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 :)