Skip to content
Snippets Groups Projects
  1. Nov 04, 2024
  2. Oct 29, 2024
    • Raphaël Gomès's avatar
      rust-vfs: rename `open` to `open_write` and `open_read` to `open` · 645d247d
      Raphaël Gomès authored
      `open` being read *and* write is surprising because it differs from the
      Rust stdlib where `std::fs::File::open` is read-only by default.
      
      More importantly, writing is more dangerous than reading, so let's make it
      more explicit.
      645d247d
    • Raphaël Gomès's avatar
      rust-status: fix a future compilation error · 644c696b
      Raphaël Gomès authored
      This was the warning by clippy 1.82.0, which explains the change:
      
      ```
      warning: this function depends on never type fallback being `()`
         --> hg-core/src/dirstate_tree/status.rs:397:5
          |
      397 | /     fn traverse_fs_directory_and_dirstate<'ancestor>(
      398 | |         &self,
      399 | |         has_ignored_ancestor: &'ancestor HasIgnoredAncestor<'ancestor>,
      400 | |         dirstate_nodes: ChildNodesRef<'tree, 'on_disk>,
      ...   |
      404 | |         is_at_repo_root: bool,
      405 | |     ) -> Result<bool, DirstateV2ParseError> {
          | |___________________________________________^
          |
          = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
          = note: for more information, see issue #123748 <https://github.com/rust-lang/rust/issues/123748>
          = help: specify the types explicitly
      note: in edition 2024, the requirement `!: rayon::iter::FromParallelIterator<()>` will fail
         --> hg-core/src/dirstate_tree/status.rs:453:28
          |
      453 |                 .collect::<Result<_, _>>()?;
          |                            ^^^^^^^^^^^^
          = note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default
      ```
      644c696b
    • Raphaël Gomès's avatar
      rust-cpython: remove outdated test · 4361d787
      Raphaël Gomès authored
      This test wasn't testing anything anymore since the feature has been removed.
      This was caught by clippy 1.82.0.
      4361d787
    • Raphaël Gomès's avatar
      rust: fix clippy lints · f90796d3
      Raphaël Gomès authored
      These were highlighted by the latest version of clippy (1.82.0).
      f90796d3
    • Raphaël Gomès's avatar
      rust: normalize `_for_unchecked_rev` naming among revlogs and the index · a3fa37bd
      Raphaël Gomès authored
      This normalizes the naming scheme between the `Revlog`, `Changelog`, etc.
      which is less suprising, though no real bugs could stem from this because of
      the type signature mismatch.
      
      The very high-level `Repo` object still uses an `UncheckedRevision` parameter
      for its methods because that's what most callers will want.
      a3fa37bd
  3. Nov 12, 2024
  4. Nov 11, 2024
  5. Dec 22, 2020
    • Matt Harbison's avatar
      sslutil: add support for clients to set TLSv1.3 as the minimum protocol · 323e3626
      Matt Harbison authored
      AFAICT, all of the TLS versions are supported by the server without doing any
      explicit work, and there's only a `devel` config to specify an exact version on
      the server side.  Clients would also use TLSv1.3 if available, but this prevents
      the server from negotiating down.  This also causes "tls1.3" to be listed in
      `hg debuginstall`, even though it was previously supported (if the Python
      intepreter supported it- IDK if there's a good way to proactively test for and
      show future protocols without requiring manual updates like this).
      
      The v1.3 tests are nested inside the v1.2 tests for simplicity.  The v1.2 blocks
      already assume v1.0 and v1.1 support, so this seems reasonable for now.  If/when
      the older protocols start getting dropped, this will have to be reworked anyway.
      323e3626
  6. Dec 21, 2020
    • Matt Harbison's avatar
      run-tests: add a 4th `HGPORT` value · 7f8d0c2c
      Matt Harbison authored
      I want to add tls1.3 support, and test-https.t already uses the existing ports
      to test tls1.0 through 1.2.  It doesn't look to me like it can easily be
      converted to a bunch of #testcases, because this also tests downgrades to prior
      versions for the given client version.
      
      This partially reverts bc010fcd836b.
      7f8d0c2c
  7. Nov 11, 2024
  8. Nov 20, 2024
  9. Nov 09, 2024
    • Matt Harbison's avatar
      sslutil: drop support for Python prior to 3.7 · 94cf83d9
      Matt Harbison authored
      There's also a block of code around line 47 related to `ssl.HAS_TLSv1` to
      determine the supported protocols that references "Python 3.7", but I'm not
      altering that because the commit referenced there wasn't landed until just prior
      to the 3.9 release, and I'm not sure what flavors of py38 might not have a
      backport.
      
      Avoid de-indenting for now for a clearer text diff.
      94cf83d9
  10. Nov 12, 2024
    • Raphaël Gomès's avatar
      rust-manifest: use `memchr` crate for all byte-finding needs · f4aede0f
      Raphaël Gomès authored
      While writing a very dumb manifest diffing algorithm for a proof-of-concept
      I saw that `Manifest::find_by_path` was much slower than I was expecting.
      
      It turns out that the Rust stdlib uses slow (all is relative) code when
      searching for byte positions for reasons ranging from portability, SIMD
      API stability, nobody doing the work, etc. `memch` is much faster for these
      purposes, so let's use it.
      
      I was measuring ~670ms of profile time in `find_by_path`, after this patch
      it went down to ~230ms.
      f4aede0f
  11. Oct 31, 2024
  12. Nov 20, 2024
  13. Nov 13, 2024
  14. Nov 16, 2024
    • Matt Harbison's avatar
      contrib: add a script to build all of the wheels on macOS · 6aa4ee2b
      Matt Harbison authored
      This is mostly a translation of `contrib/packaging/build-windows-wheels.bat`,
      except the default pythons to build can be inferred from `setup.py` and/or
      `pyproject.toml`, and all use the same configuration.  All we need to do is
      force the building of translation files, tell it to skip pypy wheels, and tell
      it to build universal2 wheels instead of for the current architecture.
      6aa4ee2b
  15. Nov 18, 2024
  16. Nov 15, 2024
  17. Nov 14, 2024
    • Matt Harbison's avatar
      contrib: add a bat file to build all of the wheels on Windows · ea9cbb0f
      Matt Harbison authored
      This is duplicated from the current CI config, to be able to build releases
      consistently outside of CI.  I don't like the duplication, but I'm not worried
      about things changing too often, so I'm not bothering with PowerShell or some
      form that would allow execution by the CI runner.  We should consider putting
      the config in `pyproject.toml`, where things like what python versions to
      support can be centrally controlled for all platforms.  The output directory is
      different from CI here, but that's fine because it is intended to run this on a
      system that is *not* hosting the CI setup, and `dist/` is more standard.  I
      dropped the `win32` part of the output because that implies the 32-bit Intel
      architecture.
      
      Apparently, arm64 builds are supported back to Python 3.9, but support is still
      experimental (with py3.13)[1].  The CI system starts arm64 support with Python
      3.11, because that's the first version that an arm64 Python installer was
      available on Windows.  This doesn't second guess that decision.
      
      The required `msgfmt.exe` was installed manually[2], as it isn't currently
      handled by the dependency installation script.  Otherwise, this was successfully
      used with an activated venv based on Python 3.12.5, and only `cibuildwheel==2.21.3`
      installed.
      
      [1] https://cibuildwheel.pypa.io/en/stable/#what-does-it-do
      [2] https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.22.5a-v1.17-r3/gettext0.22.5a-iconv1.17-shared-64.exe
      ea9cbb0f
    • Matt Harbison's avatar
      contrib: install the arm64 compiler tools in the Windows dependency script · 2e26c21f
      Matt Harbison authored
      This lets us build arm64 wheels on Windows.  We should update from VS 2017 to
      VS 2019, but that can wait until there's a clean Windows system available.
      
      There's a little bit of handwaving here because I originally installed some
      packages on the CI system by checking boxes in the GUI installer to get arm64
      support, since I didn't know the name(s) of the things needed.  Exporting the
      configuration from the GUI installer showed the list of things present, and then
      I was able to run `vs_buildtools.exe` on another system that previously had this
      dependency script run a few years ago, with just this new arg.  That allowed the
      wheels to be built (the process failed on this second system prior to this).
      The only difference between the CI system configuration prior to installing
      arm64 stuff and this second system after, is the second system has the WinXP
      support component.  Surprisingly, the arm64 WDK and arm64 CRT or Universal CRT
      doesn't seem to be required.
      2e26c21f
  18. Nov 15, 2024
  19. Nov 14, 2024
Loading