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.
We have started to isolate extra usecases for developer-only output
that is not a warning. As the section has the fairly generic name
'devel' it makes sense to tuck them there. As a result, 'all' becomes
a bit misleading so we rename it to 'all-warnings'. This will break
some developer setups but the tests are still fine and developers will
likely spot this change.
We are warning about lock acquired in the wrong order because this can create
dead-lock situation. But non-wait acquisition will not block and therefore not
create a dead-lock. So we do not need to wait in such case.
Just displaying the warning makes it quite hard to recognise the guilty code
quickly and using --traceback for all calls is not very convenient. So we
include the call site with all simple message to help developer to recognise
errors sources.
We change the wording of the developer warning:
- "lock" taken before "wlock"
+ "wlock" acquired after "lock"
The goals here are to:
- Put the "subject" as the first word,
- use "acquired" instead of "taken" since it seems more accurate.
Before this change, any call to 'wlock' after we acquired a 'lock' was issuing a
warning. This is wrong as the 'wlock' have been properly acquired before the
'lock' in a previous call.
We move the warning code to only issue such warnings when we are acquiring the
'wlock' -after- acquiring 'lock'. This is the expected behavior of this warning
from the start.
