What's wrong
file[a-] is a complete, valid glob. In glob syntax a - right before ] is a literal dash, so the class matches a or -. DotNet.Glob's tokeniser still throws IndexOutOfRangeException on it. ResolveGlob (TextFilter.cs:417-443) catches that and caches the token as unparseable (null). By the rule documented at lines 305-309, an unparseable token matches everything as a plain or required token and excludes nothing as an excluded token.
var items = new[] { "filea", "file-", "fileZ", "report" };
TextFilter.Filter(items, "file[a-]"); // -> filea, file-, fileZ, report (expected: filea, file-)
TextFilter.Filter(items, "-file[a-]"); // -> filea, file-, fileZ, report (expected: fileZ, report)
DotNet.Globbing.Glob.Parse("file[a-]"); // throws IndexOutOfRangeException
DotNet.Globbing.Glob.Parse("file[-a]").IsMatch("file-"); // true: the leading-dash form worksThe results above were observed by running against HEAD 769c9b1.
Why it matters
The "ignore unparseable tokens" fallback from #106/#110 was meant for half-typed ranges such as file[0-. It also swallows this finished, legal pattern, and nothing tells the user. The results are the opposite of what was asked for:
- The include filter shows
report, which doesn't even start with file.
- The exclusion removes nothing.
Suggested fix
In ResolveGlob, before calling Glob.Parse, rewrite each character class so that a - immediately before the closing ] moves to the front of the class, after any !:
[a-] becomes [-a][!a-] becomes [!-a]
DotNet.Glob parses that form correctly. Keep the existing catch for genuinely half-typed input such as file[0-.
Acceptance criteria: tests show that file[a-] includes filea and file- only, -file[a-] excludes exactly those, and file[0- still behaves as it does today.
What's wrong
file[a-]is a complete, valid glob. In glob syntax a-right before]is a literal dash, so the class matchesaor-. DotNet.Glob's tokeniser still throwsIndexOutOfRangeExceptionon it.ResolveGlob(TextFilter.cs:417-443) catches that and caches the token as unparseable (null). By the rule documented at lines 305-309, an unparseable token matches everything as a plain or required token and excludes nothing as an excluded token.The results above were observed by running against HEAD
769c9b1.Why it matters
The "ignore unparseable tokens" fallback from #106/#110 was meant for half-typed ranges such as
file[0-. It also swallows this finished, legal pattern, and nothing tells the user. The results are the opposite of what was asked for:report, which doesn't even start withfile.Suggested fix
In
ResolveGlob, before callingGlob.Parse, rewrite each character class so that a-immediately before the closing]moves to the front of the class, after any!:[a-]becomes[-a][!a-]becomes[!-a]DotNet.Glob parses that form correctly. Keep the existing catch for genuinely half-typed input such as
file[0-.Acceptance criteria: tests show that
file[a-]includesfileaandfile-only,-file[a-]excludes exactly those, andfile[0-still behaves as it does today.