colineberhardt / assemblyscript-regex Goto Github PK

Current behaviour - (a|b)c|a(b|c) when executed against ab returns values from both capture groups

https://github.com/ColinEberhardt/assemblyscript-regex/blob/main/.prettierignore

it would be good to find a fix / workaround for this.

I'd consider this library to be a useable POC (proof of concept) in its current state. The implementation is based around the description of regex as provided by the MDN regex cheat sheet, however, this is not a detailed description of the regex language and in some places deviates from others see - #9

At this point it probably makes sense to consider a few points:

1. What regex specification should this library use for the purposes of implementation?
2. How should this library be tested in order to meet this specification?

I've been expanding the scope of the benchmark tests, most recently adding a more complex regex (https://github.com/ColinEberhardt/assemblyscript-regex/pull/24/files#diff-42e96713f3210182cc2ac65586ac4e2025e9c8134b31f88b2da3c2f69be5f452R65) to support evaluation of algorithm changes (e.g. NFA => DFA).

However, adding this more complex regex has caused an issue which looks like it could indicate a memory leak:

baseline x 106,495 ops/sec ±1.28% (85 runs sampled)
character class x 35,063 ops/sec ±1.28% (85 runs sampled)
concatenation x 7,934 ops/sec ±1.44% (87 runs sampled)
quantifiers x 14,392 ops/sec ±1.66% (86 runs sampled)
/home/runner/work/assemblyscript-regex/assemblyscript-regex/node_modules/@assemblyscript/loader/umd/index.js:78
      throw Error(`abort: ${getString(memory, msg)} at ${getString(memory, file)}:${line}:${colm}`);
      ^

Error: abort:  at ~lib/rt/tlsf.ts:238:14
    at abort (/home/runner/work/assemblyscript-regex/assemblyscript-regex/node_modules/@assemblyscript/loader/umd/index.js:78:13)
    at ~lib/rt/tlsf/insertBlock (<anonymous>:wasm-function[2]:0x689)
    at ~lib/rt/tlsf/addMemory (<anonymous>:wasm-function[3]:0x8d1)
    at ~lib/rt/tlsf/growMemory (<anonymous>:wasm-function[8]:0xbf6)
    at ~lib/rt/tlsf/allocateBlock (<anonymous>:wasm-function[10]:0xccb)
    at ~lib/rt/tlsf/moveBlock (<anonymous>:wasm-function[17]:0x1836)
    at ~lib/rt/tlsf/reallocateBlock (<anonymous>:wasm-function[18]:0x18ff)
    at ~lib/rt/tlsf/__realloc (<anonymous>:wasm-function[19]:0x1926)
    at ~lib/rt/pure/__renew (<anonymous>:wasm-function[20]:0x1958)
    at ~lib/array/ensureSize (<anonymous>:wasm-function[56]:0x2147)

see the PR: #24

ac matched against ([a-c]){2} should return a single capture group with the value c:

https://regex101.com/r/K97m2f/1/

In the current implementation the capture group is duplicated, returning both a and c.

Hello!

Here is the test to reproduce the issue:

it("non-capturing groups should not capture with expression", () => {
  const re = new RegExp("(?:^|\\s|-)\\S", "g");
  const input = "hello, great-world";

  let match = exec(re, input);
  expect(match.matches.length).toBe(1);
  expect(match.matches[0]).toBe("h");

  match = exec(re, input);
  expect(match.matches.length).toBe(1);
  expect(match.matches[0]).toBe(" g"); // this fails and return the second letter (and each consecutive exec will return all the letters)

  match = exec(re, input);
  expect(match.matches.length).toBe(1);
  expect(match.matches[0]).toBe("-w");
});

While in Javascript:

const re = new RegExp("(?:^|\\s|-)\\S", "g");
const input = "hello, great-world";

> re.exec(input);
[ 'h', index: 0, input: 'hello, great-world', groups: undefined ]
> re.exec(input);
[ ' g', index: 6, input: 'hello, great-world', groups: undefined ]
> re.exec(input);
[ '-w', index: 12, input: 'hello, great-world', groups: undefined ]
> re.exec(input);
null

Or on one line:

'hello, great-world'.replace(/(?:^|\s|-)\S/g, x => x.toUpperCase())
> 'Hello, Great-World'

Happy to give it a shot, if you have any hint where to start looking it would probably save me a lot of time :-)

Thanks!

Once this library is a bit more mature I'd like to move to semantic versioning via semantic release

The RegExp constructor is exported as exports["RegExp#constructor"] with a signature of (this_: RegExp, regex: string, flags: string) => RegExp (all pointers, the this_ argument is typically 0 to indicate that the ctor should allocate on its own, i.e. not a super() call). During demangling, the loader creates a function exports.RegExp one can use with and without new representing it, and one can invoke new exports.RegExp(regexPtr, flagsPtr) (without this_) effectively corresponding to exports.createRegExp(regexPtr, flagsPtr), but returning a wrapper class instead of just a pointer.

There may be value in exposing createRegExp, though, for where the loader is not used, i.e. when running the binary in a C or Rust host. The AS compiler typically does this to also provide an easy to use C-like interface that works everywhere.

Great article about this:
https://jasonhpriestley.com/regex-dfa

I guess better use new RegExp("[\w]+") instead pre-compiled /[\w]+/ for example

See #35

I haven't taken a terribly structured approach to error handling, hence there may be cases where the error reporting is poor or the behaviour unexpected. Furthermore, the test suite I am using does't have many error cases.

This project has a combination of manually crafted unit tests and a larger number of tests generated from test cases used by other regex engines.

Further assistance in triaging, fixing issues and improving the test case generation process would be much appreciated!

Add CI tests that ensure:

• unit tests all pass
• code is correctly formatted
• the code can be executed both as AS and TS

In order to ease development I'd like to always ensure that this project works equally well as TypeScript. A good way to ensure this is to ruin the unit tests in TS as well as AS. see #5

I've been using the MDN regex cheatsheet as a guide to regex syntax.

Within their cheatsheat they term [xyz] a character set - which is what as-regex currently uses. However, almost every other reference I can find terms this a character class.

I think as-regex should use the more conventional terminology.

I previously tried as-pect, but hit an issue of some sort. I honestly can't recall what it was now. In the spirit of supporting the AssemblyScript ecosystem, it would be good to se as-pect.

/cc @jtenner

For the rather complex regex "^((?:[+-]\\d{6}|\\d{4}))(?:-(\\d{2})-(\\d{2})|(\\d{2})(\\d{2}))(?:(?:T|\\s+)(\\d{2})(?::(\\d{2})(?::(\\d{2})(?:[.,](\\d{1,9}))?)?|(\\d{2})(?:(\\d{2})(?:[.,](\\d{1,9}))?)?)?)?(?:([zZ])|(?:([+-])([01][0-9]|2[0-3])(?::?([0-5][0-9])(?::?([0-5][0-9])(?:[.,](\\d{1,9}))?)?)?)?)(?:\\[((?:(?:\\.\\.[-A-Za-z._]{1,12}|\\.[-A-Za-z_][-A-Za-z._]{0,12}|_[-A-Za-z._]{0,13}|[a-zA-Z](?:[A-Za-z._][-A-Za-z._]{0,12})?|[a-zA-Z]-(?:[-._][-A-Za-z._]{0,11})?|[a-zA-Z]-[a-zA-Z](?:[-._][-A-Za-z._]{0,10})?|[a-zA-Z]-[a-zA-Z][a-zA-Z](?:[A-Za-z._][-A-Za-z._]{0,9})?|[a-zA-Z]-[a-zA-Z][a-zA-Z]-(?:[-._][-A-Za-z._]{0,8})?|[a-zA-Z]-[a-zA-Z][a-zA-Z]-[a-zA-Z](?:[-._][-A-Za-z._]{0,7})?|[a-zA-Z]-[a-zA-Z][a-zA-Z]-[a-zA-Z][a-zA-Z](?:[-._][-A-Za-z._]{0,6})?)(?:\\/(?:\\.[-A-Za-z_]|\\.\\.[-A-Za-z._]{1,12}|\\.[-A-Za-z_][-A-Za-z._]{0,12}|[A-Za-z_][-A-Za-z._]{0,13}))*|Etc\\/GMT[-+]\\d{1,2}|(?:[+\\u2212-][0-2][0-9](?::?[0-5][0-9](?::?[0-5][0-9](?:[.,]\\d{1,9})?)?)?)))\\])?(?:\\[u-ca-((?:[A-Za-z0-9]{3,8}(?:-[A-Za-z0-9]{3,8})*))\\])?$", the JS implementation when matching the string 19761118 yields the following result:

'[
  "19761118",
  "1976",
  null,
  null,
  "11",
  "18",
  null,
  null,
  null,
  null,
  null,
  null,
  null,
  null,
  null,
  null,
  null,
  null,
  null,
  null,
  null
]'

The AS implementation yields the following:

  "matches": [
    "19761118",
    "1976",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "",
    "11",
    "18"
  ]

i.e. groups 4 & 5 are now at the end

Currently the CI tests (that run npm test) use node v15. However, the benchmarks use the default node version, which happens to be v10.

When running the benchmarks on node v15 they fail as follows:

$ npm run benchmark

> [email protected] benchmark
> node benchmark/benchmark.js

baseline x 134,050 ops/sec ±0.79% (88 runs sampled)
character class x 43,542 ops/sec ±2.28% (87 runs sampled)
concatenation x 9,974 ops/sec ±1.11% (86 runs sampled)
/Users/colineberhardt/Projects/as-regex/node_modules/@assemblyscript/loader/umd/index.js:78
      throw Error(`abort: ${getString(memory, msg)} at ${getString(memory, file)}:${line}:${colm}`);
      ^

Error: abort:  at ~lib/rt/tlsf.ts:238:14
    at abort (/Users/colineberhardt/Projects/as-regex/node_modules/@assemblyscript/loader/umd/index.js:78:13)
    at ~lib/rt/tlsf/insertBlock (<anonymous>:wasm-function[2]:0x69f)
    at ~lib/rt/tlsf/addMemory (<anonymous>:wasm-function[3]:0x8e7)
    at ~lib/rt/tlsf/growMemory (<anonymous>:wasm-function[8]:0xc0c)
    at ~lib/rt/tlsf/allocateBlock (<anonymous>:wasm-function[10]:0xce1)
    at ~lib/rt/tlsf/__alloc (<anonymous>:wasm-function[11]:0xd46)
    at ~lib/rt/pure/__new (<anonymous>:wasm-function[12]:0xd72)
    at ~lib/rt/__newArray (<anonymous>:wasm-function[33]:0x1d7f)
    at assembly/regexp/recursiveBacktrackingSearch (<anonymous>:wasm-function[181]:0x5025)
    at assembly/regexp/recursiveBacktrackingSearch (<anonymous>:wasm-function[181]:0x507a)

Ideally everything should run on the same node version!

There are a few features not yet supported (e.g. negative lookahead). It would be useful to add these to the parser, but fail visibly when converting to an NFA.