Its functions will be instructed to use the custom allocator as well as PCRE2 with custom allocators is better understood it is expected more of Into an earlier phase to avoid degrading performance, but as the use of Move some of the logic that was before done per thread (in the workers) If they are using the pattern matching functionality. Should make sure to have matching `grep_init()`/`grep_destroy()` calls Update `builtin/grep.c` to use that new API, but any other future users PCRE2 requires the use of a general context to override the allocatorĪnd therefore, there is a lot more code needed than in PCRE1, includingĮxtend the grep API with a "destructor" that could be called to cleanupĪny objects that were created and used globally. PCRE2, triggering a segfault in Windows (where we use nedmalloc by Tried to plug a memory leak by `free()`ing a data structure allocated by Grep: make PCRE2 aware of custom allocator 94da9193a6 (grep: add support for PCRE v2, ) didn't includeĪ way to override the system allocator, and so it is incompatible withĬustom allocators (e.g. nedmalloc). This problem became obvious when we Tested-By: Todd Zullinger Signed-off-by: Junio C Hamano why I chose the same type when declaring the variable holding the start_progress() expects the total number as an uint64_t, that's
Use values that don't fit into an int anyway. Parse-options expects in the tests of the progress output we won't Two bits of 3 end up in the "wrong" bytes on big-endian systemsĬhange the type of that variable from uint64_t to int, to match what Via parse-options's OPT_INTEGER into a uint64_t variable , so the The reason for that bogus value is that '-total's parameter is parsed + test-tool progress -total=3 Working hard total=' fail on big-endian systems, e.g. like this: In 't0500-progress-display.sh' all tests running 'test-tool progress Test-progress: fix test failures on big-endian systems Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano Mistake on this developer's part, it was never turned on in the CI/PRīuilds. This results in 2x-3x longer run times of the test phase. This helper even knows how to run the tests in parallel, but due to a `prove`): we simply implemented a new test helper to run the test suite. Suite in parallel, as Visual Studio users typically will only have a Gitīash available (which does not ship with `make` nor with support for Visual Studio uses `MSBuild`, or at least something very similar).ĭuring that transition, we needed to implement a new way to run the test `master`), however, this was changed to generate Visual Studio projectįiles and build the binaries using `MSBuild`, as this reflects moreĪccurately how Visual Studio users would want to build Git (internally, Later (but still before the patches made their way into git.git's Were implemented imitating `linux-clang`, i.e. still using the Originally, the CI/PR builds that build and test using Visual Studio Ci(visual-studio): actually run the tests in parallel
0 kommentar(er)
