An attempt to predict how deep a glob will go. This should only come into effect when the user doesn't provide an explicit depth (in the current state, when usize::MAX is passed to WalkBehavior).
The current heuristic is simple: It walks through every token, and if it's a wildcard or repetition, it bails out. Otherwise, it simply increases the maximum depth by 1 for each separator found.
I may have missed something, and I certainly don't want to break anything. I also haven't tried it in a hyper diverse set of globs; just a healthy few:
It is very very faster when ran on big directories for globs that can have this optimization applied. But I am not super confident that no globs will slip by. And I am also not confident that it won't over-predict; in fact, it definitely will for globs like a/{b/b,c/c,d/d}/e. This is solvable if I simply account for nested structures via some recursion in the try_get_max_depth function, but I'd rather get some feedback before committing too much to the implementation.
An attempt to predict how deep a glob will go. This should only come into effect when the user doesn't provide an explicit depth (in the current state, when usize::MAX is passed to WalkBehavior).
The current heuristic is simple: It walks through every token, and if it's a wildcard or repetition, it bails out. Otherwise, it simply increases the maximum depth by 1 for each separator found.
I may have missed something, and I certainly don't want to break anything. I also haven't tried it in a hyper diverse set of globs; just a healthy few:
It is very very faster when ran on big directories for globs that can have this optimization applied. But I am not super confident that no globs will slip by. And I am also not confident that it won't over-predict; in fact, it definitely will for globs like
a/{b/b,c/c,d/d}/e
. This is solvable if I simply account for nested structures via some recursion in thetry_get_max_depth
function, but I'd rather get some feedback before committing too much to the implementation.Thoughts?