Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 03 23:47
    manunio closed #335
  • Oct 03 19:55
    manunio commented #353
  • Oct 03 19:13

    epage on main

    docs: Update fuzz readme Merge pull request #353 from ma… (compare)

  • Oct 03 19:13
    epage closed #353
  • Oct 03 19:13
    epage commented #353
  • Oct 03 19:04
    manunio opened #353
  • Oct 03 14:05
    epage commented #352
  • Oct 03 11:23
    monadbobo opened #352
  • 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
ironyman
@ironyman
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 :)