cargo test on MSVC-x86

[gvanem]

Hello folks. I just moved from Cygwin's grep to rg and I like it a lot. (except the horrid --colors=x:y:z syntax)

Knowing next to nothing about Rust and Cargo, I made this simple GNU-makefile (named Makefile.Windows):

#
# Build 'rg.exe' for MSVC x86.
#
green_msg = @echo -e "\e[1;32m$(strip $(1))\e[0m"

TARGET       ?= i686-pc-windows-msvc
INSTALL_ROOT ?= $(realpath $(VSINSTALLDIR))

export RUSTFLAGS=-C target-feature=+avx2

all: target/$(TARGET)/release/rg.exe
	$(call green_msg, Do a 'make -f Makefile.Windows install' at own risk.)

target/$(TARGET)/release/rg.exe: Cargo.toml
	$(call green_msg, Building $@)
	cargo build --color never --release --target $(TARGET)
	@echo

install:
	cp --update target/$(TARGET)/release/rg.exe target/$(TARGET)/release/rg.pdb $(INSTALL_ROOT)/bin

test: target/$(TARGET)/release/rg.exe
	$(call green_msg, Running tests for $@)
	cargo test --color never --all | tee test-log.txt
	@echo

clean vclean distclean:
	rm -f test-log.txt target/.rustc_info.json
	rm -fR target/*
	- rmdir target

Running make -f Makefile.Windows test, resulted in 2 failures:

failures:
    misc::preprocessing
    misc::preprocessing_glob

test result: FAILED. 264 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 9.26s

Full log here: test-log.txt. What's this all about?

BTW. A rg --version prints:

ripgrep 13.0.0
-SIMD -AVX (compiled)

when I specified -C target-feature=+avx2. Isn't that correct?
So the -in -AVX looks like that is disabled. Or maybe my rustc is not up for AVX2?

[BurntSushi]

The failing tests are for the --pre and --pre-glob flags. It looks like there's a problem running an external script:

---- misc::preprocessing stdout ----
thread 'misc::preprocessing' panicked at '

==========
command failed but expected success!

command: "F:\\MingW32\\src\\misc\\ripgrep\\src\\target\\debug\\deps\\../rg.exe" "--path-separator" "/" "--pre" "xzcat" "Sherlock" "sherlock.xz"

cwd: c:\TEMP\ripgrep-tests\preprocessing\163

dir list: ["c:\\TEMP\\ripgrep-tests\\preprocessing\\163", "c:\\TEMP\\ripgrep-tests\\preprocessing\\163\\sherlock.xz"]

status: exit code: 2

stdout: 

stderr: sherlock.xz: preprocessor command could not start: '"f:\\CygWin32\\bin\\xzcat" "sherlock.xz"': Ingen tilgang. (os error 5)


==========
', tests\util.rs:406:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I don't know what "ingen tilgang" means. But the test should get skipped if xzcat isn't available. So it looks like there is something about your system where the test suite is finding the xzcat binary, but it can't run it for whatever reason.

when I specified -C target-feature=+avx2. Isn't that correct?
So the -in -AVX looks like that is disabled. Or maybe my rustc is not up for AVX2?

The AVX in the --version output isn't a property of the codegen, but rather, whether the requisite crate features are enabled to take advantage of some types of SIMD code. The build instructions in the README should generally explain the end user ramifications of this. More specifically though, enabling simd-accel will really only help some cases a bit when decoding UTF-16. The rest of the SIMD used in ripgrep is enabled automatically. You don't even need -C target-feature=+avx2.

(except the horrid --colors=x:y:z syntax)

Well, don't stop there. What's "horrid" about it? What would you have done better?

[gvanem]

'"f:\CygWin32\bin\xzcat" "sherlock.xz"': Ingen tilgang. (os error 5)
...
I don't know what "ingen tilgang" means.

It means No Access. My xzcat on PATH is a Cygwin symlink to f:\CygWin32\bin\xz.exe.
In addition f:\CygWin32\bin\xzcat has the System attribute set. Maybe related?
Moving that out of my PATH and using another xzcat.exe (also on my PATH), it works:

test result: ok. 266 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 9.67s

(except the horrid --colors=x:y:z syntax)

Well, don't stop there. What's "horrid" about it? What would you have done better?

I think the use of --colors "match:style:intense" is unclear. Does it make the foreground or background intense?
Like with a rg --colors "match:fg:white" --colors "match:bg:red" --colors "match:style:intense" ..., gives:

Both foreground and background. Is this intended?

I've been a happy user of the 4NT shell since 1995. With it's COLOR command and syntax:
COLOR [BRIght] fg [ON [BRIght] bg]]. So the above could be compacted into rg --colors "match:bright white on red" ...
(or rg --colors "match:bri white on red" ...).

Just my 0.02 €.

Edit: The above picture could be compacted into rg --colors "match:bright white on bright red" ...

[BurntSushi]

Yeah, looks like the tests are working correctly then.

The point about intensity is a good one. I likely made a conceptual error there because I hadn't fully understood the way that Window consoles did coloring. That's not about the syntax though. The syntax was not designed to be concise. It was designed to be extensible, since I didn't know what kind of color features I wanted to support. For example, your syntax only considers the extremely limited features of the Windows console. It doesn't account, for example, for bolding or underlining. And it also doesn't account for future additions.