Patterns have no end-of-text anchor: Anchor::EndOfText exists in AST and compiler but no parser production emits it (anchors also undocumented)

[logbie]

Summary

WFL patterns have no end-of-text anchor. Anchor::EndOfText exists in the AST and is implemented in the pattern compiler, but no parser production ever emits it, so there is no way to write it. start of text works; nothing anchors the other end. Pattern anchors are also entirely undocumented.

Reproduction

create pattern ends_ab:
    "ab" then end of text
end pattern
display ("xab" matches ends_ab)

Command:

wfl g2_end_of_text_anchor.wfl

Expected

yes — "xab" ends with ab.

No documentation citation exists, in either direction — filed as a capability
plus documentation gap, not a broken runtime.
grep -rn "start of text\|end of text" Docs/ returns zero hits: neither
Docs/04-advanced-features/pattern-matching.md nor
Docs/05-standard-library/pattern-module.md documents anchors at all, even though
the start anchor is implemented and working.

Actual

Parse errors:
error[ERROR]: Unexpected token in pattern: KeywordEnd
  ┌─ g2_end_of_text_anchor.wfl:2:15
  │
2 │     "ab" then end of text
  │               ^^^ Error occurred here

Exit code: 2.

The support is half-built. The variant and its compilation both exist:

// src/parser/ast.rs:982-985
pub enum Anchor {
    StartOfText, // start of text
    EndOfText,   // end of text
}

// src/pattern/compiler.rs:876
Anchor::EndOfText => { ... }

but the pattern parser has exactly one anchor arm, for the start:

// src/parser/stmt/patterns.rs:822-829
// Anchors
Token::KeywordStart => {
    if ... Token::KeywordOf ... Token::KeywordText { ... PatternExpression::Anchor(Anchor::StartOfText) }

grep -rn "EndOfText" src/ matches only parser/ast.rs and pattern/compiler.rs
— nothing constructs it. Verified working counterpart:

create pattern p1:
    start of text then "ab"
end pattern

→ "xab" matches p1 → no; "abx" matches p1 → yes. Correct.

Two adjacent limitations that show up in the same use case (each arguably its own
request, listed here for context, not as part of this issue): the pattern engine
has no case-insensitive mode and no negated character class, so a
/[^\w]keyword[ ]?$/i-style test cannot be expressed with patterns at all.

Environment

• wfl --version: WebFirst Language (WFL) version 26.8.4
• binary: system install C:\Program Files\wfl\bin\wfl.exe
• commit: c277d8f
• OS: Windows 11 Pro 10.0.26200
• build: release

Also reproduces on the repo build (26.8.2). No .wflcfg in scope.

Context

Found while porting G:/repos/JShrink/src/JShrink/Minifier.php (a 738-line PHP
JavaScript minifier) to WFL. JShrink's endsInKeyword() uses
preg_match('/[^\w]'.$keyword.'[ ]?$/i', $tail) over eight JS keywords.

This was encountered, not blocking: the check was rebuilt from substring +
tolowercase + contains, which is exact and reasonably readable, so nothing was
stubbed. It is filed because an anchor whose implementation is already written and
merely unreachable from the surface syntax is cheap to finish, and because the
anchor that does work is undocumented — a user has no way to discover
start of text from Docs/ today.

[logbie]

Warden assessment: confirmed — half-built feature, smallest fix in this set

Verified against main @ 36de4fa (v26.8.8). Every claim reproduces on inspection:

• grep -rn "EndOfText" src/ matches exactly two files — src/parser/ast.rs:985 (the variant) and src/pattern/compiler.rs:876 (its compilation). Nothing constructs it.
• src/parser/stmt/patterns.rs contains exactly one Anchor:: construction, at line 829, and it is StartOfText.

So the AST variant and the compiler arm are both live code that is currently unreachable. This is a genuine parser gap, not a design decision, and it is the cheapest item in this batch to close: one parser arm mirroring the existing Token::KeywordStart production.

One implementation wrinkle worth flagging before someone starts. The start anchor keys off KeywordStart, which is unambiguous in pattern position. The end anchor keys off KeywordEnd, which is not — end pattern terminates the block. The new arm therefore needs lookahead confirming KeywordOf + KeywordText before committing to an anchor, and must leave end pattern alone on the fall-through. The error in the repro (Unexpected token in pattern: KeywordEnd) is the parser correctly declining to guess.

The documentation half is worth doing in the same PR: start of text is implemented, working, and documented nowhere — so the docs gap already exists independently of the missing end anchor, and closing both together is the smaller total edit. Anchors belong in Docs/04-advanced-features/pattern-matching.md.

The two adjacent limitations you note (no case-insensitive mode, no negated character class) are real and separate; they are worth their own issues rather than being folded in here, since neither shares this one's "already implemented, just unreachable" character.

Posted by the WFL repo warden (automated triage pass).