- Nov 03, 2021
-
-
Kyle Lippincott authored
In-memory resources were disabled for macOS in 7bc1beedd718, and for all platforms in c900d962e38b. Unfortunately this made it so that we were no longer producing standalone binaries on these platforms, and would have to ship the .py and .pyc files alongside the pyoxidized binary. These changes are no longer necessary after f6b045910d82, which disabled pep517 and solved the issue we were encountering. Differential Revision: https://phab.mercurial-scm.org/D11734
-
Raphaël Gomès authored
Pierre Augier signaled on the mailing list that this fails on Pypy and pointed out the correct solution. Differential Revision: https://phab.mercurial-scm.org/D11732
-
Raphaël Gomès authored
This hasn't been updated in a while, and since we're updating the MSRV to 1.48.0, we might as well do this. Differential Revision: https://phab.mercurial-scm.org/D11733
-
- Aug 25, 2021
-
-
Raphaël Gomès authored
Debian Bullseye has just been released, and it carries `rustc 1.48.0`. This actually implies a regression that we can't really do anything about in `rhg`. See https://github.com/rust-lang/rust/issues/88825. In short, closed (or bad) standard file descriptors are reopened silently with no way of telling by the Rust runtime before `main` is executed. This means that closed fds are not forwarded to the subprocess we run in case of fallback. This is a bit sad, but probably not something worth worrying too much about. Differential Revision: https://phab.mercurial-scm.org/D11341
-
- Oct 19, 2021
-
-
Pierre-Yves David authored
It seems the format as reached a good balance. With a core of new capabilities that motivated it initially and enough new feature and room for future improvement to be a clear progress we can set a milestone for. Having the format frozen will help the feature to get real life testing, outside of the test suite. The feature itself stay experimental but the config gains a new name to avoid people enable non-frozen version by default. If too many bugs are reported during the RC we might move the format back to experimental and drop its support in future version (in favor of a new one) Differential Revision: https://phab.mercurial-scm.org/D11709
-
- Nov 01, 2021
-
-
Augie Fackler authored
-
- Oct 22, 2021
-
-
Raphaël Gomès authored
Otherwise the backslashes will work as escapes on Windows and break everything. Differential Revision: https://phab.mercurial-scm.org/D11725
-
- Oct 29, 2021
-
-
Pierre-Yves David authored
As per feedback from Dan Villiom Podlaski Christiansen in https://phab.mercurial-scm.org/D11674#179866 Differential Revision: https://phab.mercurial-scm.org/D11730
-
- Oct 28, 2021
-
-
Pierre-Yves David authored
Without this extra checks, file with fallback flags change as the only change would be overlooked. In the future we might store proper data in the dirstate and do less lookup. However, for now this will do to make sure that 6.0 is forward compatible with later version. Differential Revision: https://phab.mercurial-scm.org/D11729
-
Pierre-Yves David authored
The previous code was overlooking fallback when neither symlink not exec was supported. The number of "variants" is getting too high, so I am consolidating this in a single closure that should be easier to maintains. This also ensure that fallback flags are always taken into account. (they are not user code yet, but small experimentation shown that the feature was working as intended.) A a small side effect we need to check for symlink support more lazily and this show up in the test in a couple of places. Differential Revision: https://phab.mercurial-scm.org/D11728
-
- Apr 30, 2021
-
-
Kyle Lippincott authored
These builds do not actually include any Google-specific formatting changes; the only reason they don't include the LLVM version number is due to a decision to elide the version number from *all* LLVM/clang projects. For most builds of clang-format, even "unofficial" ones, the LLVM version will be displayed; example: ``` clang-format version 14.0.0 (https://github.com/llvm/llvm-project.git 1830ec94ac022ae0b6d6876fc2251e6b91e5931e) ``` The Google-internal build looks like this: ``` clang-format version google3-trunk (1830ec94ac022ae0b6d6876fc2251e6b91e5931e) ``` Differential Revision: https://phab.mercurial-scm.org/D10538
-
- Oct 26, 2021
-
-
Augie Fackler authored
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
- Oct 25, 2021
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D11720
-
- Oct 23, 2021
-
-
Matt Harbison authored
These were found by looking for `Any` types in the generated `*.pyi` file after running the tests. There are some more complicated types that I'm not sure of, and am leaving untyped. I also can't figure out how to get `self.hint` to be anything other than `Any` in most classes. Differential Revision: https://phab.mercurial-scm.org/D11719
-
Matt Harbison authored
I've seen this before, but this was seen as potentially `None` with pytype 2021.10.18. Differential Revision: https://phab.mercurial-scm.org/D11718
-
- Oct 21, 2021
-
-
Raphaël Gomès authored
As suggested by spectral during review of my fix of the missing return, this makes it more obvious that all cases are covered and improves readability of the functions with new names and a small docstring. Differential Revision: https://phab.mercurial-scm.org/D11715
-
- Oct 20, 2021
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D11713
-
Raphaël Gomès authored
Otherwise the compiler gets quite sad. Differential Revision: https://phab.mercurial-scm.org/D11712
-
Raphaël Gomès authored
Otherwise the compiler gets quite sad. Differential Revision: https://phab.mercurial-scm.org/D11711
-
Kyle Lippincott authored
A recent change to git (031e2f7ae195) made it an error to not specify a strategy (`--rebase`, `--no-rebase`, `--ff-only`), instead of just the warning it was previously. As far as I can tell, `--no-rebase` is the behavior we were getting before, and the only one that makes the test work. Differential Revision: https://phab.mercurial-scm.org/D11714
-
- Oct 21, 2021
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
`HGTEST_TIMEOUT` is overridden by `HGTEST_SLOWTIMEOUT` for tests marked as slow, which `test-check-pytype.t` is. So this whole time the timeout was 1500s (or 25 minutes), which is unfortunately not long enough for a *lot* of the times it's run on the CI. Differential Revision: https://phab.mercurial-scm.org/D11717
-
- Oct 20, 2021
-
-
Arseniy Alekseyev authored
chg tests fail pretty often with "Sample count: *" line disappearing. It disappears because the sample count is zero, in which case a custom message is printed. This commit makes the test succeed in that case. Differential Revision: https://phab.mercurial-scm.org/D11716
-
- Oct 21, 2021
-
-
David Demelier authored
Per 7.1.3 paragraph, from C draft: All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
-
- Oct 19, 2021
-
-
Raphaël Gomès authored
The `unittest._TextTestResult` alias has been removed. The "new" name has been available since 3.2, and we only support 3.5.3+. Differential Revision: https://phab.mercurial-scm.org/D11690
-
- Oct 20, 2021
-
-
Raphaël Gomès authored
Mercurial is not (yet) a pep517 package, but the presence of a pyproject.toml file tells newer-ish versions of pip that it should be one. This is related to 58fe6d127a01, and fixes pyoxidizer builds for the Heptapod CI. Differential Revision: https://phab.mercurial-scm.org/D11710
-
- Oct 19, 2021
-
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D11706
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D11705
-
Georges Racinet authored
This is a backout of changeset 3fffb48539ee. Issue 6554 is now considered solved, hence its mitigation has to be removed, if only for its performance cost. Differential Revision: https://phab.mercurial-scm.org/D11703
-
- Oct 18, 2021
-
-
Kyle Lippincott authored
Currently, pyoxidizer.bzl does not mention the git commit that should be checked out, so these instructions are a bit difficult to follow right now (impossible, technically), so I removed the instruction to `git checkout <Git commit>` and the admonition to use a specific version of PyOxidizer. I don't even know if the project currently builds with the "0.7.0-pre" version that was previously recommended. As fallout from that change to not "pin" to a specific PyOxidizer, I had to update the Python version to use when running the tests. While here, I added a recommendation to use `--release`, as the primary reason for this project is performance, and it may have been leaving some on the table to not have that there. Differential Revision: https://phab.mercurial-scm.org/D11698
-
Kyle Lippincott authored
It's possible that the errors are due to using an incompatible version of PyOxidizer; unfortunately the README.md file in this directory says to fetch a copy of PyOxidizer matching the commit in this pyoxidizer.bzl file, and yet the pyoxidizer.bzl file does not actually have a commit mentioned in it. By disabling in-memory modules, this appears to work on all platforms using the current head version of PyOxidizer, so let's disable them for now. Sample error (during `pyoxidizer build`): ``` error[PYOXIDIZER_PYTHON_EXECUTABLE]: adding PythonExtensionModule<name=hgext.fsmonitor.pywatchman.bser> Caused by: extension module hgext.fsmonitor.pywatchman.bser cannot be loaded from memory but memory loading required --> ./pyoxidizer.bzl:140:5 | 140 | exe.add_python_resources(exe.pip_install(["--verbose", ROOT])) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ add_python_resources() error: adding PythonExtensionModule<name=hgext.fsmonitor.pywatchman.bser> Caused by: extension module hgext.fsmonitor.pywatchman.bser cannot be loaded from memory but memory loading required ``` Differential Revision: https://phab.mercurial-scm.org/D11697
-
- Oct 19, 2021
-
-
Pierre-Yves David authored
Since the format is not frozen yet, it seems like the right moment to do it. Differential Revision: https://phab.mercurial-scm.org/D11704
-
Pierre-Yves David authored
This was overlooked in a previous commit. Differential Revision: https://phab.mercurial-scm.org/D11695
-
Pierre-Yves David authored
Tracking directory "explicitly" give use the opportunity to distinct between entry that are untracked because they are part of the directory structure and entry that are ignored/unknown files on the files system. The help is adjusted to the new semantic and the code now comply to it for both read and write. Differential Revision: https://phab.mercurial-scm.org/D11694
-
- Oct 13, 2021
-
-
Simon Sapin authored
Instead of zero, set the nanoseconds field to its correct value whenever possible and preserve it across serialization+parsing. Differential Revision: https://phab.mercurial-scm.org/D11702
-
- Oct 14, 2021
-
-
Simon Sapin authored
When comparing mtimes for equality. Some APIs simply return zero when more precision is not available. When comparing values from different sources, if only one is truncated in that way, doing a simple comparison would cause many false negatives. Differential Revision: https://phab.mercurial-scm.org/D11701
-
- Oct 19, 2021
-
-
Pierre-Yves David authored
This flag will let us use more `mtime` value in the future. For now we have a minimal handling of the flag at read time, but we will never put ourself in a situation where we will needs to writes it. See the flag documentation for details. Differential Revision: https://phab.mercurial-scm.org/D11700
-
- Oct 18, 2021
-
-
Simon Sapin authored
Keep integer seconds since the Unix epoch, together with integer nanoseconds in the `0 <= n < 1e9` range. For now, nanoseconds are still always zero. This commit is about data structure changes. Differential Revision: https://phab.mercurial-scm.org/D11684
-