... to have a solid baseline

The explicit catch on CalledProcessError will be used in a follow up
commit to ensure that python errors do not stay unnoticed.

Ref #3624

... to make our SunOS vtest build happy again

ld: fatal: file /opt/local/lib/libpcre.so: wrong ELF class: ELFCLASS64
ld: fatal: file processing errors. No output written to vjsn_test
collect2: error: ld returned 1 exit status

The issue here was order of the -L -l arguments when a (32bit) version
of a library needs to be found first in an overridden LDPATH.

Ref 12bbe31f
Ref #3559

We might want to do something about it once pcre2 is in place, but it
should be noted that concurrent matches on a vre_t could compete over
the limits we can tweak.

Refs #3559

It's more helpful than printing the invalid regular expression, that's
how the spurious "\T" was spotted.

It is interpreted as "T" by pcre but pcre2 is stricter and treats it as
a syntax error. While there may be a bit flag to ignore unknown escape
sequences, it is probably worth hardening instead.

Refs #3559

To make sure it is always readily available without an extra step, and
that it doesn't rot away missing build flags or triggerring developer
warnings like GCC's -Wtautological-constant-out-of-range-compare.

Otherwise we get it from either libvarnish or libvarnishapi.

Refs #3559

to the extent that the match operator ~ will actually accept vmod
function/method calls returning it.

Because VMODs also need an invalid ACL value to signal error, we stop
panicking for a NULL ACL and trigger a VCL failure instead.

The use case is not (yet) to generate dynamic ACLs, but rather to store
and recall global ACL symbols.

This implementation was particularly simple thanks to Dridis work
on #3555 and VCL_REGEX.

Annotate parameter tweak functions with v_matchproto_()

VCC_SymbolGet() could fail, e,g, if the token is reserved

Now with vtc to make the issue more obvious.

OKed by Dridi via IRC

Ref cf396384

Introduced by eabe58bc but soon after
made obsolete by 9b1f1d17.

This reverts commit 2bc56a4b.

We already assert that sym is not null, and we certainly don't expect a
reserved symbol to have slipped through since we already attempted the
least specific symnbol lookup.

This is not a case where we expect to fail because of user input.

When a VCL_HEADER argument is a vmod return value, it could be

- NULL for an error condition
- from a different context

Also, we should not assert on HDR_OBJ in VRT_selecthttp() to
facilitate error handling in vmods.

Fixes #3623

VCC_SymbolGet() could fail, e,g, if the token is reserved

Ref cf396384

Add test-coverage of internal function sf_parse_int()

Only the special cases get special handling.

With sanitizers it becomes too easy to trigger a timeout because of the
debug.priv_perf() invocations.

Note for later, I'm planning to change the feature syntax to this:

    feature [!]<name> [<args>...]

This way we can use `feature !sanitizer` to express the same check.

A side effect is slightly more accurate error messages.

Closes #3555

This migrates the remaining candidates for vcc_Peek*() functions using a
coccinelle semantic patch. When vcc_PeekToken*() is used in an assignment
statement it's straightforward to patch. In an expression a careful
review is needed, that's why the generated code is meant not to compile
on purpose. That's how the pattern for vcc_PrintTokens() was noticed.

The same pattern occurred 3 times while reviewing potential usage for the
new vcc_PeekToken*() functions.

Without advancing to the next token, and leaving the door open to
synthetic tokens that would otherwise interfere with direct access.

This is as far declaring symbols goes, because we can still find
hard-coded prefixes in other places. Having them in the types could
actually help centralize them for good, but this is a minimal change
for the purpose of referencing global symbols before they are defined.

Refs #3555