Repository navigation
A glob class with a large range plus anything else ("[가-힣a-z]*", "[一-龥0-9]*") matches every item, and as an exclusion ("-[一-龥a-z]*") hides nothing #184
Description
What's wrong
ToGlobCharacterList (TextFilter/TextFilter.cs, around line 608) flattens a class into an explicit character list. Once that list would exceed MaxGlobClassMembers (4096), it gives up and returns null.
ResolveGlob and DoesMatchGlob read null as "unparseable, ignore this token", the rule meant for half-typed tokens. A required token that is ignored matches everything, and an excluded one excludes nothing.
Repro (TextFilterMatchOptions.ByWholeString)
| Call | Observed | Expected |
|---|---|---|
IsMatch("README.md", "[가-힣a-z]*") |
True | False |
IsMatch("README.md", "[一-龥a-z]*") |
True | False |
IsMatch("README.md", "[一-龥0-9]*") |
True | False |
IsMatch("README.md", "-[一-龥a-z]*") |
True | False (README.md should be excluded) |
IsMatch("@", "[A-힣]") |
True | False |
The last case is a single range. It spans \, so since #157 it goes through the flattening path instead of DotNet.Glob.
Why it matters
CJK and Hangul ranges are the usual way to say "any Chinese or Korean character". Adding a-z or 0-9 to one silently turns the token into match-all, or for an exclusion, exclude-nothing. The XML docs only promise that incomplete, half-typed tokens are ignored, and this token is complete.
Suggested fix
Stop flattening large classes. Either of these works:
- Split a multi-range class into one pattern per native range.
ResolveGlobalready returns aGlob[]and matches if any of them matches. - Translate the glob to a regex with a real character class.
At minimum, a class that is well-formed but too large should throw or be reported, not be read as "half-typed".
Acceptance: the five cases above give the expected results, and half-typed tokens like file[0- are still ignored (#141, #110).
Activity
matt-edmondson commentedon Nov 4, 2026
Triage
ToGlobCharacterListand theMaxGlobClassMemberscap (TextFilter/TextFilter.cs, around line 608), and howResolveGlob/DoesMatchGlobread a null result.file[%-!]) matches every item, while the letter/digit equivalent (file[9-0]) matches none #173 (a reversed-range class also matches everything). Both come from the same root cause: "couldn't flatten" collapses into "half-typed, ignore". The flattening path dates from Glob character classes that combine a range with anything else silently drop members: [0-9a-f] doesn't match "c", [a-zA-Z] doesn't match "Q", [a-z_] doesn't match "_" #152 / PR Match every member of a glob class that mixes a range with other characters [patch] #156 and was extended by Glob class range spanning / or \ doesn't match it, and the negated class does:[.-0]misses "/",[!A-z]matches "\" #157 / PR Match a path separator inside a glob class range that spans it [patch] #164. No open PR covers this. Open PRs Match an unclosed glob bracket literally [patch] #165 (unclosed bracket) and Match a mixed-case glob range the same under both case sensitivities [patch] #168 (mixed-case ranges) touch the same glob-class code, so expect conflicts.ResolveGlobalready returnsGlob[]), or translate it to a regex character class. At minimum, report or throw for a well-formed but too-large class instead of treating it as half-typed. Fix A glob class whose only range is reversed (file[%-!]) matches every item, while the letter/digit equivalent (file[9-0]) matches none #173 in the same change if possible, and keep the A half-typed range in an excluded glob token ("-readme[a-") hides every item #110/A half-typed second glob token makes every item match under ByWordAny: "*.cs file[0-" shows readme.md and logo.png #141 half-typed cases (file[0-) ignored.Generated by Claude Code