Add _SAVE & _SAVE_AS for unnamed/named captures

[xparq]

(Requires #2)

Again, just like that of proper regexes... (Nameless ones just collecting into a vector, named ones into a map. UPDATE: Well, not that simple, though, see task 2...)

This could be a fundamental building block of subsequent parsing features.

Note: it should be used "wisely", i.e. to not nest capture ops carelessly. I mean it's fine, but probably makes little sense. E.g. I could detect it and issue a warning I guess...

• _SAVE
• _SAVE, but actually putting the result into some "reliably indexable" slot! :) Just putting it into some map using this as the key loses the "proper monotonic ordering for pseudo-indexing by enumeration" property!
  • DEF/USE etc. or dynamic rule changes etc. could also make this a mess -- but we only need to not crash. :) The rest can be simply declared UB.
  • Well, it just has to be done by a compilation phase (Grammar preprocessing/compilation phase (after construction, before parsing) #31), and index them strictly by the order of appearance (as regexes do) -- even if in a DEF rule (but multiple USEs is UB!).
• convenience getter (e.g. operator[](size_t index)) for unnamed results (via Parser)
• also for named ones then...
• _SAVE_AS "name"

---

Rather than fiddling with auto-assigning contiguous indexes to multiple matching unnamed _SAVE rules, and having distinct (disjunct) capture-results collections for the two modes, just using the stringified this pointer for the unnamed ones seems better, with a thin iterator wrapper for enumerating them. They can even go into the very same results map, perhaps!

• OK, so not in the same map...
  • First of all, users may want to query the count of named/unnamed captures separately.
  • Second, the numeric indexing of unnamed results is a tad more nuanced than just the simple ["name"] getters, and it can at least be a little simpler with numeric indexes and keeping the map ordered, and not having to slalom around the explicit name keys either.
  • The issue of name clashes between auto-indexes and "given names" disappears with 0 effort this way.

[xparq]

Just FTR:

CASE("CAPTURE: named") {
    Parser p(_{
	    _{_OPT, "_WHITESPACES"},
	    _{_SAVE_AS, "id", "_ID"},
	    _{_OPT, "_WHITESPACES"},
	    "=",
	    _{_OPT, "_WHITESPACES"},
	    _{_SAVE_AS, "val", "_DIGITS"}
    }); p.syntax.DUMP();

    CHECK(p.parse("  capture_this = 1  "));
	    CHECK(p.unnamed_captures.empty());
	    CHECK(p.named_captures.size() == 2);
	    CHECK(p["id"] == "capture_this");
	    CHECK(p["val"] == "1");
    CHECK(p.parse("  or_this = 22 // Wow, fake comments! ;)"));
	    CHECK(p.unnamed_captures.empty());
	    CHECK(p.named_captures.size() == 2);
	    CHECK(p["id"] == "or_this");
	    CHECK(p["val"] == "22");

    CHECK(!p.parse("not this = one"));
}

CASE("CAPTURE: nested") {
    RULE code = _{_MANY, _{_OR, "_ID", "=", "_DIGITS", ";", "_WHITESPACES"} };
    RULE block_in = _{"<", _{_SAVE_AS, "inner", code}, ">"};
    RULE block_out = _{"<", _{_SAVE_AS, "outer",
			    _{ _{_OPT, code}, _{_OPT, block_in}, _{_OPT, code} },
		    }, ">"};

    Parser p(block_out); p.syntax.DUMP();

    CHECK(p.parse("<outer <inner> block>"));
    CHECK(p["inner"] == "inner");
    CHECK(p["outer"] == "outer <inner> block");

    CHECK(p.parse("<outer < x = 1; y = 2; > block>"));
    CHECK(p["inner"] == " x = 1; y = 2; "); //! Mind the spaces...
    CHECK(p["inner"] !=  "x = 1; y = 2;" ); //! Mind the spaces...
    CHECK(p["outer"] == "outer < x = 1; y = 2; > block");
}