Skip to content
Snippets Groups Projects
  1. Apr 05, 2022
    • Raphaël Gomès's avatar
      d3709fa5
    • Raphaël Gomès's avatar
      relnotes: add notes for 6.1.1 · 5bd6bcd3
      Raphaël Gomès authored
      This also fixes the header for 6.1 from 6.1rc0
    • Raphaël Gomès's avatar
      rust-hgpath: add `repr(transparent)` to `HgPath` · 9dcfd1d0
      Raphaël Gomès authored
      It's been stabilized a long time ago, so let's not rely on an implementation
      detail now.
      
      Differential Revision: https://phab.mercurial-scm.org/D12433
      9dcfd1d0
    • Raphaël Gomès's avatar
      rust-dirstatemap: correctly decrement the copies counter · ce919b1a
      Raphaël Gomès authored
      This was caught when writing unit tests for the `DirstateMap`. We were always
      setting `had_copy_source` to `false` since we erased the value just before.
      
      Differential Revision: https://phab.mercurial-scm.org/D12432
      ce919b1a
    • Raphaël Gomès's avatar
      rust-dirstatemap: properly decrement counter for tracked descendants · fbc02ccc
      Raphaël Gomès authored
      I found this bug when writing unit tests after the fact for the `DirstateMap`.
      We never decremented the tracked descendants counter since we were always
      resetting the node data before reading it. This also drops the use of `state`,
      in favor of the new API to get that information.
      
      Differential Revision: https://phab.mercurial-scm.org/D12431
      fbc02ccc
    • Raphaël Gomès's avatar
      rust-dirstate: panic if the DirstateMap counters go below 0 · 2593873c
      Raphaël Gomès authored
      When modifying the API I hit some... interesting errors (trying to allocate
      178GB of RAM, for example) because I failed to keep the counters correctly
      updated.
      
      This counter underflow is likely to happen when code is changed around
      and can have up to eat-your-dirstate level of consequences, which is not nice.
      
      The very small runtime cost of checking these counters should really not be an
      issue and will help us uncover bugs when/if they do appear in the future.
      
      Differential Revision: https://phab.mercurial-scm.org/D12430
      2593873c
    • Raphaël Gomès's avatar
      rust: fix unsound `OwningDirstateMap` · dd6b67d5
      Raphaël Gomès authored
      As per the previous patch, `OwningDirstateMap` is unsound. Self-referential
      structs are difficult to implement correctly in Rust since the compiler is
      free to move structs around as much as it wants to. They are also very rarely
      needed in practice, so the state-of-the-art on how they should be done within
      the Rust rules is still a bit new.
      
      The crate `ouroboros` is an attempt at providing a safe way (in the Rust sense)
      of declaring self-referential structs. It is getting a lot attention and was
      improved very quickly when soundness issues were found in the past: rather than
      relying on our own (limited) review circle, we might as well use the de-facto
      common crate to fix this problem. This will give us a much better chance of
      finding issues should any new ones be discovered as well as the benefit of
      fewer `unsafe` APIs of our own.
      
      I was starting to think about how I would present a safe API to the old struct
      but soon realized that the callback-based approach was already done in
      `ouroboros`, along with a lot more care towards refusing incorrect structs.
      
      In short: we don't return a mutable reference to the `DirstateMap` anymore, we
      expect users of its API to pass a `FnOnce` that takes the map as an argument.
      This allows our `OwningDirstateMap` to control the input and output lifetimes
      of the code that modifies it to prevent such issues.
      
      Changing to `ouroboros` meant changing every API with it, but it is relatively
      low churn in the end. It correctly identified the example buggy modification of
      `copy_map_insert` outlined in the previous patch as violating the borrow rules.
      
      Differential Revision: https://phab.mercurial-scm.org/D12429
      dd6b67d5
    • Raphaël Gomès's avatar
      rust: explain why the current `OwningDirstateMap` is unsound · cfd270d8
      Raphaël Gomès authored
      See inline comments.
      
      Differential Revision: https://phab.mercurial-scm.org/D12428
      cfd270d8
  2. Apr 01, 2022
  3. Jul 23, 2021
  4. Mar 24, 2022
  5. Mar 29, 2022
    • Yuya Nishihara's avatar
      tags: fix typo in fast path detection of fnode resolution (issue6673) · d4b66dc5
      Yuya Nishihara authored
      If I understand it, mctx.readfast() is unreliable here if p1/p2 .hgtags
      nodes differ, and tags on that branch would be randomly discarded
      depending on which parent were picked.
      
      The test case added by this patch would fail only on zstd-compressed
      repository. I didn't try hard to stabilize the failure case.
      d4b66dc5
  6. Mar 28, 2022
  7. Mar 22, 2022
  8. Mar 21, 2022
    • Martin von Zweigbergk's avatar
      unamend: abort if commit was not created by `hg [un]amend` · 9120c0cd
      Martin von Zweigbergk authored
      `hg unamend` can currently undo any kind of rewrite, as long as it has
      an obsmarker. However, that has quite unexpected results if you run it
      after e.g. `hg rebase` (expecting it to behave like a generic `hg
      undo` command), because it updates to the predecessor and leaves the
      old changes in the working copy. I think it's better to allow `hg
      unamend` only after `hg amend` (and after `hg unamend` because that's
      documented as being supported).
      
      Differential Revision: https://phab.mercurial-scm.org/D12390
      9120c0cd
  9. Mar 17, 2022
  10. Mar 19, 2022
  11. Mar 18, 2022
  12. Mar 15, 2022
  13. Mar 14, 2022
  14. Mar 01, 2022
  15. Feb 28, 2022
  16. Feb 21, 2022
  17. Feb 18, 2022
  18. Feb 22, 2022
  19. Feb 18, 2022
Loading