From 803c44784509d31a8abb4297acda19bd680f667a Mon Sep 17 00:00:00 2001 From: Adam Reichold Date: Fri, 19 May 2023 14:23:53 +0200 Subject: [PATCH] searcher: re-enable mmap on 32-bit architectures memmap2 v0.3.0 introduced a regression when trying to map files larger than 4GB on 32-bit architectures[1] which was subsequently fixed in v0.3.1[2]. This commit bumps locked version of the memmap2 dependency to the current v0.5.0 and reverts fdfc418be55ff91e0c2efad6a3e27db054cb5534 to re-enable mmap on 32-bit architectures as a different approach to fixing [3]. This was tested to report matches from the end of a 5GB file using MinGW and Wine. Ref #1911, PR #2000 [1] https://github.com/RazrFalcon/memmap2-rs/commit/5e271224c8411c89b42060294f9393cfc7b12a2a [2] https://github.com/RazrFalcon/memmap2-rs/commit/9aa838aed99a4879d8357ff295a0ca1c98ba1ae5 [3] https://github.com/BurntSushi/ripgrep/issues/1911 --- crates/searcher/src/searcher/mmap.rs | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/crates/searcher/src/searcher/mmap.rs b/crates/searcher/src/searcher/mmap.rs index 83fc423..0ab2d53 100644 --- a/crates/searcher/src/searcher/mmap.rs +++ b/crates/searcher/src/searcher/mmap.rs @@ -71,16 +71,6 @@ impl MmapChoice { if !self.is_enabled() { return None; } - if !cfg!(target_pointer_width = "64") { - // For 32-bit systems, it looks like mmap will succeed even if it - // can't address the entire file. This seems to happen at least on - // Windows, even though it uses to work prior to ripgrep 13. The - // only Windows-related change in ripgrep 13, AFAIK, was statically - // linking vcruntime. So maybe that's related? But I'm not sure. - // - // See: https://github.com/BurntSushi/ripgrep/issues/1911 - return None; - } if cfg!(target_os = "macos") { // I guess memory maps on macOS aren't great. Should re-evaluate. return None;