• Dridi Boukelmoune's avatar
    vre: Migrate to pcre2 · 6014912e
    Dridi Boukelmoune authored
    Now that VRE is the only regular expression API we use, we can migrate
    its backend to pcre2. The existing 'pcre_*' parameters are also renamed
    to reflect this migration, and 'pcre_match_limit_recursion' gets special
    treatment and is renamed to pcre2_depth_limit.
    
    This creates an additional API breakage in VRE: the `match_recursion`
    field in `struct vre_limits` is also renamed. One last breakage is the
    removal of `VRE_has_jit` used by only one undocumented varnishtest
    feature, and the pcre_jit feature is only used by one test case that no
    longer fails.
    
    The pcre jit compilation feature was broken anyway: sealing it at
    compile time will not reflect what VRE actually links to. Once we have
    a test case needing the jit feature, we can introduce a better API for
    that check.
    
    There is one outstanding performance problem, the ovector that was
    previously allocated on the stack now needs to be allocated from the
    heap. It might be possible to implement a pcre2 context to fix that or
    maybe pool them, but for now we have heap allocations on the critical
    path. The VRE_sub() function makes sure to make a single ovector
    allocation (technically a pcre2_match_data allocation) since it's the
    only one guaranteed to loop on a single regular expression for the
    `regsuball()` use case.
    
    On the documentation front, the SmartOS installation instructions are
    hidden for lack of a pcre2 package.
    
    Closes #3616
    Closes #3559
    6014912e
Dockerfile.archlinux 290 Bytes