Wed, 17 Jan 2018 13:02:42 +0100 win32text: use 'tiprev' when appropriate
Boris Feld <boris.feld@octobus.net> [Wed, 17 Jan 2018 13:02:42 +0100] rev 35675
win32text: use 'tiprev' when appropriate This is cleaner than the current 'len(repo) - 1' form.
Wed, 17 Jan 2018 13:01:38 +0100 patchbomb: use 'tiprev' when appropriate
Boris Feld <boris.feld@octobus.net> [Wed, 17 Jan 2018 13:01:38 +0100] rev 35674
patchbomb: use 'tiprev' when appropriate This is cleaner than the current 'len(repo) - 1' form.
Thu, 04 May 2017 02:28:19 +0200 revset: use 'tiprev' when appropriate
Boris Feld <boris.feld@octobus.net> [Thu, 04 May 2017 02:28:19 +0200] rev 35673
revset: use 'tiprev' when appropriate This is cleaner than the current 'len(repo) - 1' forms
Thu, 04 May 2017 02:24:04 +0200 changelog: use 'tiprev()' in 'tip()'
Boris Feld <boris.feld@octobus.net> [Thu, 04 May 2017 02:24:04 +0200] rev 35672
changelog: use 'tiprev()' in 'tip()' Since 'tip()' is just a node version of 'tiprev()' we should reuse the code.
Thu, 04 May 2017 02:23:21 +0200 changelog: introduce a 'tiprev' method
Boris Feld <boris.feld@octobus.net> [Thu, 04 May 2017 02:23:21 +0200] rev 35671
changelog: introduce a 'tiprev' method Accessing tiprev is a common need through the code base. It is usually done using "len(changelog) -1". That form is tedious and error-prone. For example, it will give wrong results on filtered changelog (if the unfiltered tip is filtered). As a result, we introduce a simple 'tiprev()' method to provide this exact information in a nice way.
Wed, 17 Jan 2018 15:47:38 -0500 contrib: add some basic scaffolding for some fuzz test targets
Augie Fackler <augie@google.com> [Wed, 17 Jan 2018 15:47:38 -0500] rev 35670
contrib: add some basic scaffolding for some fuzz test targets I'd like to get the majority of our C code covered by automated fuzz testing. I've started with bdiff because it was already decoupled from libpython and therefore was fairly quick to produce a working fuzzer. The code here is a little odd because I've been having trouble convincing libfuzzer to define a main and I threw in the towel. This code will also work with github.com/google/oss-fuzz, and once it lands in our main repo I intend to enable automated fuzzing in oss-fuzz with reports going to our security alias. Differential Revision: https://phab.mercurial-scm.org/D1875
Wed, 17 Jan 2018 15:56:12 -0500 formatting: enforce clang-format on all .cc files as well as .c files
Augie Fackler <augie@google.com> [Wed, 17 Jan 2018 15:56:12 -0500] rev 35669
formatting: enforce clang-format on all .cc files as well as .c files As part of my upcoming fuzzer patch we're going to grow some .cc files. They're not part of the release build (they're only used for fuzzing, which requires clang 6 which in turn implies a working C++ compiler), so I'm not terribly worried about growing some C++ files. Differential Revision: https://phab.mercurial-scm.org/D1874
Wed, 17 Jan 2018 15:28:38 -0500 hghave: add test for clang 6 and later
Augie Fackler <augie@google.com> [Wed, 17 Jan 2018 15:28:38 -0500] rev 35668
hghave: add test for clang 6 and later clang 6 includes integrated libfuzzer support, which makes fuzzer stuff a little easier to work with. Differential Revision: https://phab.mercurial-scm.org/D1873
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip