function rejectSomeDirectEvalExpressions(src) {
    const lineNumber = getLineNumber(src, someDirectEvalPattern);
    if (lineNumber < 0) {
      return src;
    }
    const name = getSourceURL(src);
    throw new SyntaxError(
      `Possible direct eval expression rejected at ${name}:${lineNumber}. (SES_EVAL_REJECTED)`,
    );
  }
Heuristically reject some text that seems to contain a direct eval
expression, with both false positives and false negavives. To reject without
parsing, `rejectSomeDirectEvalExpressions` may will also reject some other
text as well. It may also accept source text that contains a direct eval
written oddly, such as `(eval)(src)`. This false negative is not a security
vulnerability. Rather it is a compat hazard because it will execute as
an indirect eval under the SES-shim but as a direct eval on platforms that
support SES directly (like XS).

The shim cannot correctly emulate a direct eval as explained at
https://github.com/Agoric/realms-shim/issues/12
If we did not reject direct eval syntax, we would
accidentally evaluate these with an emulation of indirect eval. To
prevent future compatibility problems, in shifting from use of the
shim to genuine platform support for the proposal, we should
instead statically reject code that seems to contain a direct eval
expression.

As with the dynamic import expression, to avoid a full parse, we do
this approximately with a regexp, that will also reject strings
that appear safely in comments or strings. Unlike dynamic import,
if we miss some, this only creates future compat problems, not
security problems. Thus, we are only trying to catch innocent
occurrences, not malicious one. In particular, `(eval)(...)` is
direct eval syntax that would not be caught by the following regexp.

Exported for unit tests.

@param { string } src
@returns { string }