• Leszek Swirski's avatar
    Revert "[regexp] Rewrite error handling" · 2193f691
    Leszek Swirski authored
    This reverts commit e80ca24c.
    
    Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679)
    
    Original change's description:
    > [regexp] Rewrite error handling
    > 
    > This patch modifies irregexp's error handling. Instead of representing
    > errors as C strings, they are represented as an enumeration value
    > (RegExpError), and only converted to strings when throwing the error
    > object in regexp.cc. This makes it significantly easier to integrate
    > into SpiderMonkey. A few notes:
    > 
    > 1. Depending on whether the stack overflows during parsing or
    >    analysis, the stack overflow message can vary ("Stack overflow" or
    >    "Maximum call stack size exceeded"). I kept that behaviour in this
    >    patch, under the assumption that stack overflow messages are
    >    (sadly) the sorts of things that real world code ends up depending
    >    on.
    > 
    > 2. Depending on the point in code where the error was identified,
    >    invalid unicode escapes could be reported as "Invalid Unicode
    >    escape", "Invalid unicode escape", or "Invalid Unicode escape
    >    sequence". I fervently hope that nobody depends on the specific
    >    wording of a syntax error, so I standardized on the first one. (It
    >    was both the most common, and the most consistent with other
    >    "Invalid X escape" messages.)
    > 
    > 3. In addition to changing the representation, this patch also adds an
    >    error_pos field to RegExpParser and RegExpCompileData, which stores
    >    the position at which an error occurred. This is used by
    >    SpiderMonkey to provide more helpful messages about where a syntax
    >    error occurred in large regular expressions.
    > 
    > 4. This model is closer to V8's existing MessageTemplate
    >    infrastructure. I considered trying to integrate it more closely
    >    with MessageTemplate, but since one of our stated goals for this
    >    project was to make it easier to use irregexp outside of V8, I
    >    decided to hold off.
    > 
    > R=​jgruber@chromium.org
    > 
    > Bug: v8:10303
    > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
    > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
    > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#66784}
    
    TBR=jgruber@chromium.org,iireland@mozilla.com
    
    Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: v8:10303
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
    Commit-Queue: Leszek Swirski <leszeks@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#66786}
    2193f691
regexp-parser.h 12.5 KB