FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 02 Aug 2017 01:03:20 +0900] rev 33815
i18n: make hggettext use original docstring to compute offset
Before this patch, hggettext uses __doc__ of each functions to compute
offset of document text.
But __doc__ of many functions is already modified by decorators in
registrar (e.g. @templatekeyword adds ":NAME: " prefix to it), and
hggettext can not find it out in original source.
This causes many "unknown offset in ..." warning at "make update-pot",
and leaving them might cause overlooking serious problems.
This patch makes hggettext use original docstring, which decorators in
registrar save into _origdoc, to compute offset.
Even after this patch, there are still a few "unknown offset in ..."
warning at "make update-pot" for specific reasons. These will be fixed
later one by one.
Matthieu Laneuville <matthieu.laneuville@octobus.net> [Fri, 11 Aug 2017 14:21:49 +0200] rev 33814
run-tests: also color the summary messages (skipped, failed...)
Filip Filmar <filmil@gmail.com> [Sun, 13 Aug 2017 00:17:13 -0700] rev 33813
crecord: fixes the formatting of the select status in the status line
The status line in the crecord has the "space" status field which has variable
length depending on the length of the status label in the language of choice.
In English, the status labels are "space: deselect" and "space:select". The
"deselect" label is 2 glyphs longer. This makes the terminal output jump
around if the terminal width is just right so that the shorter label makes
the status line 1 line long, and the longer label makes it 2 lines long.
This patch formats the selected status into a fixed-width field. The field
width is the maximum of the lengths of the two possible labels, to account for
differing translations and label lengths. This should make the label behavior
uniform across localizations.
There does not seem to be a test for crecord, so I verified the change manually
with a local build of 'hg'.
Yuya Nishihara <yuya@tcha.org> [Mon, 14 Aug 2017 13:35:26 +0900] rev 33812
cext: move PyInt macros to charencode.c properly
Python3 build was broken at
e9996bd7203f.
Yuya Nishihara <yuya@tcha.org> [Mon, 14 Aug 2017 15:50:40 +0900] rev 33811
py3: change encoding.localstr to a subclass of bytes, not str
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Aug 2017 11:10:35 +0900] rev 33810
bundle2: relax the condition to update transaction.hookargs
This is just a micro optimization. If hookargs is empty, nothing should be
necessary.
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Aug 2017 11:05:56 +0900] rev 33809
bundle2: raise ProgrammingError for invalid call of addhookargs()
It should be hard error. Also fixed the error message as s/hooks/hookargs/.
Alex Gaynor <agaynor@mozilla.com> [Fri, 14 Jul 2017 19:27:28 +0000] rev 33808
merge: removed sorting in casefolding detection, for a slight performance win
It was not required for the correctness of the algorithm.
Differential Revision: https://phab.mercurial-scm.org/D30
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 10 Aug 2017 21:00:30 -0700] rev 33807
tests: verify that peer instances only expose interface members
Our abstract interfaces are more useful if we guarantee that
implementations conform to certain rules. Namely, we want to ensure
that objects implementing interfaces don't expose new public
attributes that aren't part of the interface. That way, as long as
consumers don't access "internal" attributes (those beginning with
"_") then (in theory) objects implementing interfaces can be swapped
out and everything will "just work."
We add a test that enforces our "no public attributes not part
of the abstract interface" rule.
We /could/ implement "interface compliance detection" at run-time.
However, that is littered with problems.
The obvious solutions are custom __new__ and __init__ methods.
These rely on derived types actually calling the parent's
implementation, which is no sure bet. Furthermore, __new__ and
__init__ will likely be called before instance-specific attributes
are assigned. In other words, they won't detect public attributes
set on self.__dict__. This means public attribute detection won't
be robust.
We could work around lack of robust self.__dict__ public attribute
detection by having our interfaces implement a custom __getattribute__,
__getattr__, and/or __setattr__. However, this incurs an undesirable
run-time penalty. And, subclasses could override our custom
method, bypassing the check.
The most robust solution is a non-runtime test. So that's what this
commit implements. We have a generic function for validating that an
object only has public attributes defined by abstract classes. Then,
we instantiate some peers and verify a newly constructed object
plays by the rules.
Differential Revision: https://phab.mercurial-scm.org/D339
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 10 Aug 2017 20:58:28 -0700] rev 33806
wireproto: use new peer interface
The wirepeer class provides concrete implementations of peer interface
methods for calling wire protocol commands. It makes sense for this
class to inherit from the peer abstract base class. So we change
that.
Since httppeer and sshpeer have already been converted to the new
interface, peerrepository is no longer adding any value. So it has
been removed. httppeer and sshpeer have been updated to reflect the
loss of peerrepository and the inheritance of the abstract base
class in wirepeer.
The code changes in wirepeer are reordering of methods to group
by interface.
Some Python code in tests was updated to reflect changed APIs.
.. api::
peer.peerrepository has been removed. Use repository.peer abstract
base class to represent a peer repository.
Differential Revision: https://phab.mercurial-scm.org/D338
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Aug 2017 18:00:19 -0700] rev 33805
httppeer: use peer interface
This is similar to what we did to sshpeer. Quirks and all.
Differential Revision: https://phab.mercurial-scm.org/D337
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Aug 2017 17:59:48 -0700] rev 33804
sshpeer: use peer interface
We need the same @property conversion of ui like we did for localpeer.
We renamed _capabilities() to capabilities() to satisfy the new
naming requirement.
However, since we're inheriting from wireproto.wirepeer which inherits
from peer.peerrepository and provides its own code accessing
_capabilities(), we need to keep the old alias around. This wonkiness
will disappear once wirepeer is cleaned up in subsequent commits.
We also implement methods for basepeer that are identical to the
defaults in peer.peerrepository in preparation for the removal of
peerrepository.
Differential Revision: https://phab.mercurial-scm.org/D336
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 09 Aug 2017 23:52:25 -0700] rev 33803
localrepo: use peer interfaces
We now have a formal abstract base class for peers. Let's
transition the peer classes in localrepo to it.
As part of the transition, we reorder methods so they are grouped
by interface and match the order they are defined in the interface.
We also had to change self.ui from an instance attribute to a
property to satisfy the @abstractproperty requirement.
As part of this change, we uncover the first "bug" as part of
enforcing interfaces: stream_out() wasn't implemented on localpeer!
This isn't technically a bug since the repo isn't advertising the
stream capability, so clients shouldn't be attempting to call it.
But I don't think there's a good reason why this is the case.
We implement a dummy method to satisfy the interface requriements.
We can make localpeer instances streamable as a future enhancement.
# no-check-commit
Differential Revision: https://phab.mercurial-scm.org/D335
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Aug 2017 16:47:25 -0700] rev 33802
repository: implement generic capability methods on peer class
These methods are part of the peer interface, are generic, and can
be implemented in terms of other members of the peer interface. So we
implement them on the peer base class as a convenience.
The implementation is essentially copied from peer.py. The code
in peer.py will eventually be deleted.
Differential Revision: https://phab.mercurial-scm.org/D334