Summary:
A large portion of `ui` is config handling. Split it to a separate class so we
can pass that separate class to places that need pure configuration.
Some `develwarn`s are skipped since the new class does not have access to fout
or ferr.
Reviewed By: DurhamG
Differential Revision: D16683787
fbshipit-source-id: d823b9e5fc6f8ed08fff3401ab3502ad3c434f00
Summary: The profiling result is now logged as a native Rust Event::Profile type.
Reviewed By: markbt
Differential Revision: D15710674
fbshipit-source-id: 699324937c07e7f639c93570a56b4f26ea0dddf1
Summary:
The in-core blackbox command displays blackbox entries in the given time range.
The `blackbox` command provided by the blackbox extension was removed. They
can still be accessed via `.hg/blackbox.log`, though.
Tests are updated. Most `| grep` patterns were changed to use structured pattern
matching `--pattern` instead. Tests that are not interesting (ex. bundlebackup,
since we are moving away from bundle files slowly) are just removed.
Reviewed By: markbt
Differential Revision: D15640718
fbshipit-source-id: 7e5da60ca2b15ae9495d0242b340a066979d5a4f
Summary:
When writing a blackbox log entry, only include the current commit if the repo
has already loaded the changelog. Otherwise, finding out what the current
commit is will load the changelog, which is wasteful, and may cause a
re-entrant call back into blackbox logging.
Reviewed By: xavierd
Differential Revision: D15539413
fbshipit-source-id: 48c27b053b9db7ce5c2d4b1991020adaea720c21
Summary:
Change the crash header to just a single line without blaming extensions or
Python. This makes the crash log shorter, and easier to read when there are
crashes in run-tests.py diffs.
Remove `ui.supportcontact` since it's no longer used.
Reviewed By: sfilipco
Differential Revision: D14393982
fbshipit-source-id: 3ede8d3d3d8fd5d125944a9a750350d3ce356b14
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
We want to have two possible Python entry points for Mercurial:
- pure-python one (`hg/hg` script, the one which is renamed into `hg.real` during FB installation)
- the one to be called from a Rust binary
The reason we can't reuse the `hg/hg` to be called form the Rust binary is because this script will eventually not exist. We also need something in the known location, so we chose to put `entrypoint.py` into `mercurial/`.
This means that both the `hg` script and the `hg.rust` binary need to be able to find the `mercurial/` directory on the system. Traditionally, `hg` contained a `LIBDIR@` string, which was replaced with the parent directory of a `mercurial/` dir at install time. Thus we could install Mercurial in non-standard locations if we needed to. We keep this functionality for the `hg` script.
`mercurial/entrypoint.py` however knows that it lives under `mercurial/` and that `hgext/` and `hgdemandimport/` live alongside `mercurial/`. Thus, the parent dir of `mercurial/` is added as a first item of `sys,path` in `entrypoint.py`.
In case `entrypoint.py` is called from a Rust binary, Python import logic also adds the entire `mercurial/` dir to `sys.path`. This is not desired, since we use `absolute_import` and want to only be able to import things as `from mercurial import smth`. A good example is `json`: even with `absolute_import` enabled `import json` loads `mercurial/json.py` if hg is called as a Rust binary. Therefore, we explicitly remove `mercurial/` from `sys.path`.
Reviewed By: quark-zju
Differential Revision: D9336157
fbshipit-source-id: 22f69e7782d549915c91ef9a0ad0ed29f62a9304
Summary:
fsmonitor would trigger buggylocking before the test extension. So let's update
the test to skip that part if fsmonitor is used.
Reviewed By: DurhamG
Differential Revision: D8869845
fbshipit-source-id: ef88e06be85de472a53d4b678e331a8374ccc9b1
Summary:
When running with a Python runtime with a slightly different zlib module,
some `zlib.compress` outputs are different. Some tests are testing the
length, or the content of `zlib.compress` output, directly or indirectly.
That's causing issues.
This patch adds a `common-zlib` hghave test so it can be used to gate tests
checking zlib output. Some lengths are also changed to glob patterns to be
compatible.
Reviewed By: ryanmce
Differential Revision: D6937735
fbshipit-source-id: 2328a39d7f2022f16d51f61b6178568b26dfe2fb
Summary:
Both chg and a packed python binary can add extra traceback
entries. So let's grep out the important lines.
Reviewed By: DurhamG
Differential Revision: D6879869
fbshipit-source-id: e97de7d2cfe512de2340ebb25e8ac93c360d5b9e
The hotfix that drops devel warnings lost it's test fixes in the latest rebase.
This adds them back.
(grafted from c8005d3b0d065f148672e799b4a05821dacf76f5)
(grafted from a0134574e5429c6c8b493270fe2e050e707401fb)
(grafted from 5d7d4d7c382dbdfdbee29f756ed89d2923716f06)
(grafted from 17a1c05f7dd723447808f146c47e778486e34c72)
(grafted from 94d0e522d808f5126a48be614838ffa125e2b001)
(grafted from 75c5f73252a5bae8742b0323ea689ca858baa753)
(grafted from 5c48dc2dea6a08c511f0b535eb4647d5c675bd30)
(grafted from 7817f8cc763105df882b96304285c7bf0763b1c4)
(grafted from 67951163d1fcc3f69542deae05cd8a118e2cdc6b)
(grafted from 4652ab4536eaf1fa8280ea40dfa40e2f6f18dcf1)
The original condition was a bit harsh for extension authors since third-party
extensions need to preserve compatibility with older Mercurial versions, where
no defaults would be loaded from the configtable. So let's silence the warning
if the given default value matches, which should be harmless.
Now that all known options are declared, we setup a warning to make sure it will
stay this way.
We disable the warning in two tests checking other behavior with random options.
The test fails when run with the "--chg" option. Therefore, this
commit makes it compatible with chg.
Test Plan:
Ran the test "test-devel-warnings.t' with and without the "--chg"
option
Differential Revision: https://phab.mercurial-scm.org/D915
Some of the extra data need to be registered earlier than they currently are
(eg: config items). We first factor out the logic to registered them in a small
function before reusing it in the next changeset.
In Pypy 5.6.0, traceback exception classes are not displayed with their full
qualified name.
Instead of displaying mercurial.error.ProgrammingError, Pypy displays
ProgrammingError.
Update the test to support both version.
In some case, the default of one value is derived from other value. We add a
way to register them anyway and an associated devel-warning.
The registration is very naive for the moment. We might be able to have a
better way for registering each of these cases but it could be done later.
we wrap 'repo.svfs.audit' to check for the store lock when accessing file in
'.hg/store' for writing. This caught a couple of instance where the transaction
was released after the lock, we should probably have a dedicated checker for
that case.
When the appropriate developer warnings are enabled, We wrap 'repo.vfs.audit' to
check for locks when accessing file in '.hg' for writing. Another changeset will
add a 'ward' for the store vfs (svfs).
This check system has caught a handful of locking issues that have been fixed
in previous series (mostly in 4.0). I expect another batch to be caught in third
party extensions.
We introduce two real exceptions from extensions 'blackbox.log' (because a lot of
read-only operations add entry to it), and 'last-email.txt' (because 'hg email'
is currently a read only operation and there is value to keep it this way).
In addition we are currently allowing bisect to operate outside of the lock
because the current code is a bit hard to get properly locked for now. Multiple
clean up have been made but there is still a couple of them to do and the freeze
is coming.
If the option is registered, there is already a default value available and
passing a new one is at best redundant. So we issue a deprecation warning in
this case.
(note: there will be case were the default value will not be as simple as what
is currently possible. We'll upgrade the configitems code to handle them in
time.)
Several benefits:
* Gets close the comment describing it
* Splits off unrelated comment about "backup" argument
* Error checking is customarily done early
* If we added an early return to the method, it would still
consistently fail if there was an existing transaction (so
we would find and fix that case quickly)
One test needs updating with for this change, because we no longer
create the backup bundle before we fail. I don't see much reason to
create that backup bundle. If some command was adding content and then
trying to strip it as well within the transaction, we would have a
backup for the user, but the risk of that not being discovered in
development seems very small.
cmdutil.command wasn't a member of the registrar framework only for a
historical reason. Let's make that happen. This patch keeps cmdutil.command
as an alias for extension compatibility.
Our current deprecation warning mechanism relies on ui object. They are case
where we cannot have access to the UI object. On a general basis we avoid using
the python mechanism for deprecation warning because up to Python 2.6 it is
exposing warning to unsuspecting user who cannot do anything to deal with them.
So we build a "safe" strategy to hide this warnings behind a flag in an
environment variable. The test runner set this flag so that tests show these
warning. This will help us marker API as deprecated for extensions to update
their code.
The quoting logic here was actually insufficient, and would have had
bogus b-prefixes on Python 3. shellquote seems more appropriate
anyway. Surprisingly, only two tests have output changes, and both of
them look reasonable to me (both are in blackbox logs).
Spotted by Yuya during review.
This is an example usage of ProgrammingError. Let's start migrating
RuntimeError to ProgrammingError.
The code only runs when devel.all-warnings or devel.check-locks is set, so
it does not affect the end-user experience.
Per discussion at 7d927e65eaf2 [1], we need "callcatch" in worker.py. Move
it to scmutil.py to avoid cycles.
Note that dispatch's callcatch handles some additional high-level exceptions
related to config parsing, and commands. Moving them to scmutil will make
scmutil depend on "commands" or require "_formatparse" and "_getsimilar"
(and "difflib") to be moved as well. In the worker use-case, it is forked
when config and commands are fully loaded. So it should not care about those
exceptions.
[1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087116.html
And refactor dispatch.py to use it. As you can see, the resulting code
is much simpler.
I was tempted to inline _runcommand as part of writing this series.
However, a number of extensions wrap _runcommand. So keeping it around
is necessary (extensions can't easily wrap runcommand because it calls
hooks before and after command execution).
We have been warning about transactions without locks for about a year (and
three releases), third party extensions had a fair grace period to fix their
code, we are moving lack of locking to a hard failure in order to protect users
against repository corruption.
The lack of locking for a transation is about to change from a warning to an
error. We first extract the test decidated to this warning to make the next
changeset clearer.
When we introduce the develwarning, we did not had an official deprecation API
and infrastructure. We can now officially deprecate the old way with a version
deadline.
Whatever the future of __del__ in Mercurial is, that devel-warning test is not
about testing the automatic transaction rollback and we should explicitly call
release.
This change make this tests pass with pypy, as pypy try less hard to call
__del__ at program exit.
As discussed on the list, we are adding an official way to keep old API around
for a short time in order to help third party developer to catch up. The
deprecated API will issue developer warning (issued by default during test runs)
to warn extensions authors that they need to upgrade their code without
instantaneously breaking tool chains and normal users.
The version is passed as an explicit argument so that developer think about it
and a potential future script can automatically check for it.
This is not build as a decorator because accessing the 'ui' instance will likely
be different each time. The message is also free form because deprecated API are
replaced in a variety of ways. I'm not super happy about the final rendering of
that message, but this is a developer oriented warning and I would like to move
forward.
