Last alternative gets dropped from whitelist regex

[agausmann]

When using whitelists with alternation, it seems that the last alternative is not checked during matching, which can result in some items not getting matched.

Input C/C++ Header

test.h:

#define EMSCRIPTEN_RESULT_SUCCESS 0
#define EMSCRIPTEN_RESULT_DEFERRED 1
#define EM_TRUE 1
#define EM_FALSE 0
int emscripten_test();

Bindgen Invocation

# Pick one of the following whitelists:
WHITELIST='^_?em_|^_?emscripten_|^_?EM_|^_?EMSCRIPTEN_'
#WHITELIST='^_?em_|^_?EMSCRIPTEN_|^_?EM_|^_?emscripten_'

bindgen --whitelist-type="$WHITELIST" --whitelist-function="$WHITELIST" --whitelist-var="$WHITELIST" test.h

Actual Results

With the first whitelist:

pub const EM_TRUE: u32 = 1;
pub const EM_FALSE: u32 = 0;
extern "C" {
    pub fn emscripten_test() -> ::std::os::raw::c_int;
}

With the second whitelist:

pub const EMSCRIPTEN_RESULT_SUCCESS: u32 = 0;
pub const EMSCRIPTEN_RESULT_DEFERRED: u32 = 1;
pub const EM_TRUE: u32 = 1;
pub const EM_FALSE: u32 = 0;

Expected Results

All of the definitions from the given header should match under both whitelists, resulting in the following bindings under either whitelist:

pub const EMSCRIPTEN_RESULT_SUCCESS: u32 = 0;
pub const EMSCRIPTEN_RESULT_DEFERRED: u32 = 1;
pub const EM_TRUE: u32 = 1;
pub const EM_FALSE: u32 = 0;
extern "C" {
    pub fn emscripten_test() -> ::std::os::raw::c_int;
}

Appending a non-matching alternative to the whitelist produces the expected output:

WHITELIST='^_?em_|^_?emscripten_|^_?EM_|^_?EMSCRIPTEN_|^$'

[agausmann]

The problem is in RegexSet::build(). When the regular expressions are given to the inner regex::RegexSet, they are wrapped in anchors using format!("^{}$", item), which isn't completely sanitary.

In my case, my whitelist regex becomes ^^_?em_|^_?emscripten_|^_?EM_|^_?EMSCRIPTEN_$. Since alternation has the lowest precedence, the leading anchor only applies to the first alternative, and the trailing anchor only applies to the last alternative.

A quick fix without modifying the behavior for other uses would be to change the format string to "^({})$", since alternation stays within capture groups.

This makes me wonder why the regular expression is implicitly wrapped in the first place. It might not be a good practice, especially if it is not well-documented. It's possible that the original author of this whitelist regex thought it was a raw regular expression input since they added their own anchors.