dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibJS/Runtime/RegExpObject.h

88 lines
3 KiB
C
Raw Normal View History

LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
/*
Userland: Use mattco@serenityos.org for my copyright headers
2021-04-22 20:53:07 -03:00
* Copyright (c) 2020, Matthew Olsson <mattco@serenityos.org>
LibJS: Store RegExp flags as a bitmask This avoids having to do O(n) contains() in the various flag accessors. Yields a ~20% speed-up on the following microbenchmark: const re = /foo/dgimsvy; for (let i = 0; i < 1_000_000; ++i) re.flags;
2024-10-25 12:29:03 -03:00
* Copyright (c) 2024, Andreas Kling <andreas@ladybird.org>
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
*/
#pragma once
LibJS: Store RegExp flags as a bitmask This avoids having to do O(n) contains() in the various flag accessors. Yields a ~20% speed-up on the following microbenchmark: const re = /foo/dgimsvy; for (let i = 0; i < 1_000_000; ++i) re.flags;
2024-10-25 12:29:03 -03:00
#include <AK/EnumBits.h>
LibJS: Separate RegExpCreate into RegExpAlloc and RegExpInitialize RegExp.prototype.compile will require invoking RegExpInitialize on an already-existing RegExpObject. Break up RegExpCreate into RegExpAlloc and RegExpInitialize to support this.
2021-08-20 10:14:27 -03:00
#include <AK/Optional.h>
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 11:34:37 -03:00
#include <AK/Result.h>
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
#include <AK/String.h>
LibJS: Enable EXPLICIT_SYMBOL_EXPORT and annotate minimum symbol set
2025-07-19 17:49:30 -03:00
#include <LibJS/Export.h>
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
#include <LibJS/Runtime/Object.h>
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
#include <LibRegex/ECMAScriptRegex.h>
LibJS: Hook up Regex<ECMA262> to RegExpObject and implement `test()' This makes RegExpObject compile and store a Regex<ECMA262>, adds all flag-related properties, and implements `RegExpPrototype.test()` (complete with 'lastIndex' support) :^) It should be noted that this only implements `test()' using the builtin `exec()'.
2020-11-18 19:20:00 -03:00
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
namespace JS {
LibJS: Enable EXPLICIT_SYMBOL_EXPORT and annotate minimum symbol set
2025-07-19 17:49:30 -03:00
JS_API ThrowCompletionOr<GC::Ref<RegExpObject>> regexp_create(VM&, Value pattern, Value flags);
LibJS: Revert Enable EXPLICIT_SYMBOL_EXPORT This reverts commit c14173f651f5a50fdb86beb4b79487454a00f3f6. We should only annotate the minimum number of symbols that external consumers actually use, so I am starting from scratch to do that
2025-07-19 14:41:08 -03:00
ThrowCompletionOr<GC::Ref<RegExpObject>> regexp_alloc(VM&, FunctionObject& new_target);
LibJS: Implement (mostly) String.prototype.match JavaScript has a couple of different ways to run a regular expression on a string. This adds support for one more. :^)
2021-03-14 07:03:11 -03:00
LibJS: Hook up the 'v' (unicodeSets) RegExp flag
2022-07-16 02:44:03 -03:00
struct ParseRegexPatternError {
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
Utf16String error;
LibJS: Hook up the 'v' (unicodeSets) RegExp flag
2022-07-16 02:44:03 -03:00
};
LibRegex: Compile ECMAScript patterns from UTF-16 Accept Utf16View patterns at the LibRegex compile boundary and pass UTF-16 or ASCII storage directly into the Rust regex parser. This keeps JavaScript regular expression construction from converting patterns through UTF-8 when LibRegex can consume the same UTF-16 representation used by LibJS. Update RegExp construction, HTML pattern validation, the regex fuzzer, and LibRegex tests to use the UTF-16 compile API.
2026-06-22 08:07:20 -03:00
ErrorOr<Utf16String, ParseRegexPatternError> parse_regex_pattern(Utf16View const& pattern, bool unicode, bool unicode_sets);
ThrowCompletionOr<Utf16String> parse_regex_pattern(VM& vm, Utf16View const& pattern, bool unicode, bool unicode_sets);
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 11:34:37 -03:00
LibJS: Export symbols causing linker errors in various consumers After LibJS had its symbol exports optimized the targets js, test-js, test262-runner, test-wasm, and LibWeb began to get linker errors after the work to add Windows support for test-web and ladybird targets. These extra JS_API annotations fix all those linker errors.
2025-08-03 18:05:09 -03:00
class JS_API RegExpObject : public Object {
LibJS+LibWeb: Add JS::Object::inherits(class_name) To allow implementing the DOM class hierarchy in JS bindings, this patch adds an inherits() function that can be used to ask an Object if it inherits from a specific C++ class (by name). The necessary overrides are baked into each Object subclass by the new JS_OBJECT macro, which works similarly to C_OBJECT in LibCore. Thanks to @Dexesttp for suggesting this approach. :^)
2020-06-21 10:14:02 -03:00
JS_OBJECT(RegExpObject, Object);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
GC_DECLARE_ALLOCATOR(RegExpObject);
LibJS+LibWeb: Add JS::Object::inherits(class_name) To allow implementing the DOM class hierarchy in JS bindings, this patch adds an inherits() function that can be used to ask an Object if it inherits from a specific C++ class (by name). The necessary overrides are baked into each Object subclass by the new JS_OBJECT macro, which works similarly to C_OBJECT in LibCore. Thanks to @Dexesttp for suggesting this approach. :^)
2020-06-21 10:14:02 -03:00
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
public:
LibJS: Store RegExp flags as a bitmask This avoids having to do O(n) contains() in the various flag accessors. Yields a ~20% speed-up on the following microbenchmark: const re = /foo/dgimsvy; for (let i = 0; i < 1_000_000; ++i) re.flags;
2024-10-25 12:29:03 -03:00
enum class Flags {
HasIndices = 1 << 0,
Global = 1 << 1,
IgnoreCase = 1 << 2,
Multiline = 1 << 3,
DotAll = 1 << 4,
UnicodeSets = 1 << 5,
Unicode = 1 << 6,
Sticky = 1 << 7,
};
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
static GC::Ref<RegExpObject> create(Realm&);
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
static GC::Ref<RegExpObject> create(Realm&, Utf16String pattern, Utf16String flags);
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
ThrowCompletionOr<GC::Ref<RegExpObject>> regexp_initialize(VM&, Value pattern, Value flags);
LibRegex: Compile ECMAScript patterns from UTF-16 Accept Utf16View patterns at the LibRegex compile boundary and pass UTF-16 or ASCII storage directly into the Rust regex parser. This keeps JavaScript regular expression construction from converting patterns through UTF-8 when LibRegex can consume the same UTF-16 representation used by LibJS. Update RegExp construction, HTML pattern validation, the regex fuzzer, and LibRegex tests to use the UTF-16 compile API.
2026-06-22 08:07:20 -03:00
Utf16String escape_regexp_pattern() const;
LibJS: Separate RegExpCreate into RegExpAlloc and RegExpInitialize RegExp.prototype.compile will require invoking RegExpInitialize on an already-existing RegExpObject. Break up RegExpCreate into RegExpAlloc and RegExpInitialize to support this.
2021-08-20 10:14:27 -03:00
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 03:41:28 -03:00
virtual void initialize(Realm&) override;
Libraries: Use default constructors/destructors in LibJS https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:25:06 -03:00
virtual ~RegExpObject() override = default;
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
LibJS: Port RegExp flags and patterns to UTF-16
2025-08-06 12:28:18 -03:00
Utf16String const& pattern() const { return m_pattern; }
Utf16String const& flags() const { return m_flags; }
LibJS: Store RegExp flags as a bitmask This avoids having to do O(n) contains() in the various flag accessors. Yields a ~20% speed-up on the following microbenchmark: const re = /foo/dgimsvy; for (let i = 0; i < 1_000_000; ++i) re.flags;
2024-10-25 12:29:03 -03:00
Flags flag_bits() const { return m_flag_bits; }
LibJS: Implement RegExp legacy static properties RegExp legacy static properties Spec url is https://github.com/tc39/proposal-regexp-legacy-features
2022-10-16 21:59:27 -03:00
Realm& realm() { return *m_realm; }
Realm const& realm() const { return *m_realm; }
bool legacy_features_enabled() const { return m_legacy_features_enabled; }
void set_legacy_features_enabled(bool legacy_features_enabled) { m_legacy_features_enabled = legacy_features_enabled; }
void set_realm(Realm& realm) { m_realm = &realm; }
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
regex::ECMAScriptRegex const* cached_regex() const { return m_cached_regex; }
void set_cached_regex(regex::ECMAScriptRegex const* ptr) const { m_cached_regex = ptr; }
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
private:
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 18:51:28 -03:00
RegExpObject(Object& prototype);
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
RegExpObject(Utf16String pattern, Utf16String flags, Object& prototype);
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 18:51:28 -03:00
LibJS: Add fast_is<T> helpers for all the primitive wrapper objects The JS runtime is full of checks for is<NumberObject> and friends. They were showing up in a Speedometer profile as ~1% spent in dynamic_cast, and this basically chops that down to nothing.
2025-03-25 05:34:06 -03:00
virtual bool is_regexp_object() const final { return true; }
LibWeb: Add missing visit_edges implementation to RegExpObject
2024-04-05 14:41:25 -03:00
virtual void visit_edges(Visitor&) override;
LibJS: Port RegExp flags and patterns to UTF-16
2025-08-06 12:28:18 -03:00
Utf16String m_pattern;
Utf16String m_flags;
LibJS: Store RegExp flags as a bitmask This avoids having to do O(n) contains() in the various flag accessors. Yields a ~20% speed-up on the following microbenchmark: const re = /foo/dgimsvy; for (let i = 0; i < 1_000_000; ++i) re.flags;
2024-10-25 12:29:03 -03:00
Flags m_flag_bits { 0 };
LibJS: Implement RegExp legacy static properties RegExp legacy static properties Spec url is https://github.com/tc39/proposal-regexp-legacy-features
2022-10-16 21:59:27 -03:00
bool m_legacy_features_enabled { false }; // [[LegacyFeaturesEnabled]]
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
mutable regex::ECMAScriptRegex const* m_cached_regex { nullptr };
LibJS: Implement RegExp legacy static properties RegExp legacy static properties Spec url is https://github.com/tc39/proposal-regexp-legacy-features
2022-10-16 21:59:27 -03:00
// Note: This is initialized in RegExpAlloc, but will be non-null afterwards
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
GC::Ptr<Realm> m_realm; // [[Realm]]
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
};
LibJS: Add fast_is<T> helpers for all the primitive wrapper objects The JS runtime is full of checks for is<NumberObject> and friends. They were showing up in a Speedometer profile as ~1% spent in dynamic_cast, and this basically chops that down to nothing.
2025-03-25 05:34:06 -03:00
template<>
inline bool Object::fast_is<RegExpObject>() const { return is_regexp_object(); }
LibJS: Store RegExp flags as a bitmask This avoids having to do O(n) contains() in the various flag accessors. Yields a ~20% speed-up on the following microbenchmark: const re = /foo/dgimsvy; for (let i = 0; i < 1_000_000; ++i) re.flags;
2024-10-25 12:29:03 -03:00
AK_ENUM_BITWISE_OPERATORS(RegExpObject::Flags);
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 20:05:49 -03:00
}
Reference in a new issue Copy permalink