Summary
mizchi/bit_ignore 0.48.0 treats Gitignore character classes and general backslash escapes as literal pattern characters. As a result, valid rules such as [ab].txt and file\?.txt fail to match the intended paths.
Both cases reproduce with the published package. I also checked current main at 2681c3bc815d01aa56e678f45eb98e268c052481; the relevant matcher still has the same behavior.
Minimal reproduction
Create these three files in an empty directory, then run moon test --target native.
moon.mod
name = "repro/bit-ignore"
version = "0.0.0"
import {
"mizchi/bit_ignore@0.48.0",
}
moon.pkg
import {
"mizchi/bit_ignore" @ignore,
} for "wbtest"
repro_wbtest.mbt
///|
test "character class" {
let matcher = @ignore.Matcher::new()
matcher.add_rules("", "[ab].txt\n")
assert_true(matcher.is_ignored("a.txt", false))
}
///|
test "escaped wildcard" {
let matcher = @ignore.Matcher::new()
matcher.add_rules("", "file\\?.txt\n")
assert_true(matcher.is_ignored("file?.txt", false))
}
Both assertions fail because is_ignored returns false. Expected: both return true.
Git confirms the expected matches. With this .gitignore:
git check-ignore --no-index -v -- a.txt 'file?.txt' reports both rules as matching (the paths do not need to exist).
Cause and impact
match_glob_precompiled_range only distinguishes literal equality, ?, and *. Character classes/ranges/negated classes and escaped metacharacters therefore do not have Gitignore semantics.
This affects consumers using the library to decide which files to ignore or copy without rendering. For example, a class-based exclusion may unexpectedly leave a binary file selected for text processing.
Could the matcher support Gitignore character classes and backslash escapes, with regressions covering [ab], [0-9], [!0-9], \?, \*, and escaped brackets? Until then, documenting the unsupported syntax would also help library consumers.
Environment
- Published package:
mizchi/bit_ignore@0.48.0
- Reproduced on macOS, native backend
moon 0.1.20260920 (914d7da)
moonc v0.10.14+7d59c7ec9
Summary
mizchi/bit_ignore0.48.0 treats Gitignore character classes and general backslash escapes as literal pattern characters. As a result, valid rules such as[ab].txtandfile\?.txtfail to match the intended paths.Both cases reproduce with the published package. I also checked current
mainat2681c3bc815d01aa56e678f45eb98e268c052481; the relevant matcher still has the same behavior.Minimal reproduction
Create these three files in an empty directory, then run
moon test --target native.moon.mod
moon.pkg
repro_wbtest.mbt
Both assertions fail because
is_ignoredreturnsfalse. Expected: both returntrue.Git confirms the expected matches. With this
.gitignore:git check-ignore --no-index -v -- a.txt 'file?.txt'reports both rules as matching (the paths do not need to exist).Cause and impact
match_glob_precompiled_rangeonly distinguishes literal equality,?, and*. Character classes/ranges/negated classes and escaped metacharacters therefore do not have Gitignore semantics.This affects consumers using the library to decide which files to ignore or copy without rendering. For example, a class-based exclusion may unexpectedly leave a binary file selected for text processing.
Could the matcher support Gitignore character classes and backslash escapes, with regressions covering
[ab],[0-9],[!0-9],\?,\*, and escaped brackets? Until then, documenting the unsupported syntax would also help library consumers.Environment
mizchi/bit_ignore@0.48.0moon 0.1.20260920 (914d7da)moonc v0.10.14+7d59c7ec9