-
Notifications
You must be signed in to change notification settings - Fork 745
Confusing behavior of regex parameters #1783
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I understand why the anchors are added, because it makes it easier to specify exact matches, but I'm not happy with the effect it has when regular expressions are being used. When I give a regular expression, I generally expect it to be evaluated as-is. For example, to specify a prefix, I'd expect that I'd be able to write a raw regular expression like On the other hand, it might be acceptable behavior, considering that
|
Also #2195 may be relevant, if it shows that this problem is biting users. |
When this option is enabled, bindgen won't parentesize and surround any regex with ^ and $. Fixes rust-lang#1783
Solved via #2345 |
Right now, the regex set implementation used by
bindgen
adds anchors to user-provided expressions so that they must match the entire input string. I can't find this anywhere in the documentation, and it has caused problems before (#1755). Inspired by this, I did a bit of research.Of the ~600 crates that depend on
bindgen
, about half of them use builder functions that accept regexes, for example, thewhitelist
andblacklist
functions. Of those crates, there are around 30 (5% of all dependents, 4% when weighted by download count) that currently add anchors to their regexes that aren't necessary.Another 30 crates use alternation in their regexes, which is bug-prone because of how it interacts with the implicit anchors. Many of these uses aren't technically correct, even if they do work correctly within the scope of the crate.
I'm creating this issue to start a discussion about whether this is a problem that needs to be fixed, and if so, how we could fix it without causing breakage for existing users.
The text was updated successfully, but these errors were encountered: