git/grep.c, branch v2.16.2

Merge branch 'ab/pcre2-grep'

2017-12-13T21:28:54Z

"git grep" compiled with libpcre2 sometimes triggered a segfault, which is being fixed. * ab/pcre2-grep: grep: fix segfault under -P + PCRE2 <=10.30 + (*NO_JIT) test-lib: add LIBPCRE1 & LIBPCRE2 prerequisites

grep: fix segfault under -P + PCRE2 <=10.30 + (*NO_JIT)

2017-11-24T07:12:26Z

Fix a bug in the compilation of PCRE2 patterns under JIT (the most common runtime configuration). Any pattern with a (*NO_JIT) verb would segfault in any currently released PCRE2 version: $ git grep -P '(*NO_JIT)hi.*there' Segmentation fault That this segfaulted was a bug in PCRE2 itself, after reporting it[1] on pcre-dev it's been fixed in a yet-to-be-released version of PCRE (presumably released first as 10.31). Now it'll die with: $ git grep -P '(*NO_JIT)hi.*there' fatal: pcre2_jit_match failed with error code -45: bad JIT option But the cause of the bug is in our own code dating back to my 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01). As explained at more length in the comment being added here, it isn't sufficient to just check pcre2_config() to see whether the JIT should be used, pcre2_pattern_info() also has to be asked. This is something I discovered myself when fiddling around with PCRE2 verbs in patterns passed to git. I don't expect that any user of git has encountered this given the obscurity of passing PCRE2 verbs through to the library, along with the relative obscurity of (*NO_JIT) itself. 1. "How am I supposed to use PCRE2 JIT in the face of (*NO_JIT) ?" ( & https://lists.exim.org/lurker/thread/20171123.101502.7f0d38ca.en.html) on the pcre-dev mailing list Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

grep: show non-empty lines before functions with -W

2017-11-21T00:36:06Z

Non-empty lines before a function definition are most likely comments for that function and thus relevant. Include them in function context. Such a non-empty line might also belong to the preceding function if there is no separating blank line. Stop extending the context upwards also at the next function line to make sure only one extra function body is shown at most. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

grep: update boundary variable for pre-context

2017-11-21T00:36:06Z

Function context can be bigger than -A/-B/-C context. To find the beginning of the combined context we search backwards. Currently we check at each loop iteration what we're looking for and determine the effective upper boundary based on that. Simplify this a bit by setting the variable "from" to the lowest unshown line number up front if we're looking for a function line and set it back to the required -B/-C context line number when we find one. This prepares the ground for the next patch; no functional change intended. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

Merge branch 'ab/pcre-v2'

2017-11-15T03:14:34Z

Building with NO_LIBPCRE1_JIT did not disable it, which has been fixed. * ab/pcre-v2: grep: fix NO_LIBPCRE1_JIT to fully disable JIT

grep: fix NO_LIBPCRE1_JIT to fully disable JIT

2017-11-13T03:49:53Z

If you have a pcre1 library which is compiled with JIT enabled then PCRE_STUDY_JIT_COMPILE will be defined whether or not the NO_LIBPCRE1_JIT configuration is set. This means that we enable JIT functionality when calling pcre_study even if NO_LIBPCRE1_JIT has been explicitly set and we just use plain pcre_exec later. Fix this by using own macro (GIT_PCRE_STUDY_JIT_COMPILE) which we set to PCRE_STUDY_JIT_COMPILE only if NO_LIBPCRE1_JIT is not set and define to 0 otherwise, as before. Reviewed-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'as/grep-quiet-no-match-exit-code-fix'

2017-08-23T21:13:12Z

"git grep -L" and "git grep --quiet -L" reported different exit codes; this has been corrected. * as/grep-quiet-no-match-exit-code-fix: git-grep: correct exit code with --quiet and -L

git-grep: correct exit code with --quiet and -L

2017-08-18T02:02:23Z

The handling of `status_only` no longer interferes with the handling of `unmatch_name_only`. `--quiet` no longer affects the exit code when using `-L`/`--files-without-match`. Signed-off-by: Anthony Sottile Signed-off-by: Junio C Hamano

grep: recurse in-process using 'struct repository'

2017-08-02T21:26:46Z

Convert grep to use 'struct repository' which enables recursing into submodules to be handled in-process. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

grep: remove redundant REG_NEWLINE when compiling fixed regex

2017-06-30T17:06:24Z

Remove the redundant REG_NEWLINE regcomp() flag from the code that compiles a fixed-string regular-expression. The REG_NEWLINE causes metacharacters such as "." to match a newline, since the basic_regex_quote_buf() function being called here escapes all metacharacters using REG_NEWLINE is confusing and redundant. The use of this flag was introduced as an unintended emergent property of 793dc676e0 ("grep/icase: avoid kwsset when -F is specified", 2016-06-25). That change amended the existing regflags, which were initialized to REG_NEWLINE in init_grep_defaults() assuming a subsequent non-fixed regcomp(). Manual testing reveals that this was always redundant, since no flags of any use were inherited from opt->regflags even back then. 793dc676e0 passes all tests with this on top: diff --git a/grep.c b/grep.c index 627ae3e3e8..89e84ed7fd 100644 --- a/grep.c +++ b/grep.c @@ -407,3 +407,3 @@ static void compile_fixed_regexp(struct grep_pat *p, struct grep_opt *opt) basic_regex_quote_buf(&sb, p->pattern); - regflags = opt->regflags & ~REG_EXTENDED; + regflags = 0; if (opt->ignore_case) Since this isn't used for anything and never was, remove it to reduce confusion when reading this code. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano