summaryrefslogtreecommitdiff
path: root/Meta/Lagom/Tools/CodeGenerators
AgeCommit message (Collapse)Author
2021-11-11Everywhere: Pass AK::StringView by valueAndreas Kling
2021-11-10LibWeb: Make property_initial_value() return a NonnullRefPtrSam Atkins
The finale! Users can now be sure that the value is valid, which makes things simpler.
2021-11-10LibWeb: Ensure that CSS initial values are always valid :^)Sam Atkins
First off, this verifies that an initial value is always provided in Properties.json for each property. Second, it verifies that parsing that initial value succeeds. This means that a call to `property_initial_value()` will always return a valid StyleValue. :^)
2021-11-10LibWeb: Remove concept of CSS pseudo-propertiesSam Atkins
We don't need them any more, so they're gone. :^)
2021-11-09LibUnicode: Parse the CLDR's defaultContent.json locale listTimothy Flynn
This file contains the list of locales which default to their parent locale's values. In the core CLDR dataset, these locales have their own files, but they are empty (except for identity data). For example: https://github.com/unicode-org/cldr/blob/main/common/main/en_US.xml In the JSON export, these files are excluded, so we currently are not recognizing these locales just by iterating the locale files. This is a prerequisite for upgrading to CLDR version 40. One of these default-content locales is the popular "en-US" locale, which defaults to "en" values. We were previously inferring the existence of this locale from the "en-US-POSIX" locale (many implementations, including ours, strip variants such as POSIX). However, v40 removes the "en-US-POSIX" locale entirely, meaning that without this change, we wouldn't know that "en-US" exists (we would default to "en"). For more detail on this and other v40 changes, see: https://cldr.unicode.org/index/downloads/cldr-40#h.nssoo2lq3cba
2021-11-05IPCCompiler: Remove now-unused ability to hardcode magic numberBen Wiederhake
2021-11-02LibWeb: Convert is_named_property_exposed_on_object to ThrowCompletionsIdan Horowitz
This is the last usage of old-style exceptions in the WrapperGenerator.
2021-10-31LibWeb: Convert throw_dom_exception_if_needed() to ThrowCompletionOrTimothy Flynn
This changes Web::Bindings::throw_dom_exception_if_needed() to return a JS::ThrowCompletionOr instead of an Optional. This allows callers to wrap the invocation with a TRY() macro instead of making a follow-up call to should_return_empty(). Further, this removes all invocations to vm.exception() in the generated bindings.
2021-10-31LibWeb: Convert all generated bindings to ThrowCompletionOrTimothy Flynn
This also required converting URLSearchParams::for_each and the callback function it invokes to ThrowCompletionOr. With this, the ReturnType enum used by WrapperGenerator is removed as all callers would be using ReturnType::Completion.
2021-10-24LibJS: Rename PropertyName to PropertyKeyAndreas Kling
Let's use the same name as the spec. :^)
2021-10-22LibJS: Convert Array AOs to ThrowCompletionOrIdan Horowitz
2021-10-21LibJS: Convert NativeFunction::{call,construct}() to ThrowCompletionOrLinus Groh
Both at the same time because many of them call construct() in call() and I'm not keen on adding a bunch of temporary plumbing to turn exceptions into throw completions. Also changes the return value of construct() to Object* instead of Value as it always needs to return an object; allowing an arbitrary Value is a massive foot gun.
2021-10-20LibJS: Rename define_native_function => define_old_native_functionIdan Horowitz
This method will eventually be removed once all native functions are converted to ThrowCompletionOr
2021-10-20LibJS: Add ThrowCompletionOr versions of the JS native function macrosIdan Horowitz
The old versions were renamed to JS_DECLARE_OLD_NATIVE_FUNCTION and JS_DEFINE_OLD_NATIVE_FUNCTION, and will be eventually removed once all native functions were converted to the new format.
2021-10-19LibWeb: Distinguish between integer and number when checking StyleValuesSam Atkins
2021-10-19LibWeb: Distinguish between length and percentage valuesSam Atkins
Though most CSS properties accept either, some do not, so distinguishing between them lets us catch some invalid values at parse time.
2021-10-18LibWeb: Implement DOMTokenList for managing space-separated tokens listsTimothy Flynn
DOMTokenList is used as the return type of, e.g., the Element.classList property.
2021-10-18LibWeb: Add initial support for IDL methods with variadic parametersTimothy Flynn
Adds support for methods whose last parameter is a variadic DOMString. We constructor a Vector<String> of the remaining arguments to pass to the C++ implementation.
2021-10-18LibJS: Convert to_u16() to ThrowCompletionOrIdan Horowitz
2021-10-18LibJS: Convert to_u32() to ThrowCompletionOrIdan Horowitz
2021-10-18LibJS: Convert to_i32() to ThrowCompletionOrIdan Horowitz
2021-10-17LibWeb: Implement (most of) NamedNodeMap to store attributesTimothy Flynn
2021-10-17LibWeb: Implement Attribute closer to the spec and with an IDL fileTimothy Flynn
Note our Attribute class is what the spec refers to as just "Attr". The main differences between the existing implementation and the spec are just that the spec defines more fields. Attributes can contain namespace URIs and prefixes. However, note that these are not parsed in HTML documents unless the document content-type is XML. So for now, these are initialized to null. Web pages are able to set the namespace via JavaScript (setAttributeNS), so these fields may be filled in when the corresponding APIs are implemented. The main change to be aware of is that an attribute is a node. This has implications on how attributes are stored in the Element class. Nodes are non-copyable and non-movable because these constructors are deleted by the EventTarget base class. This means attributes cannot be stored in a Vector or HashMap as these containers assume copyability / movability. So for now, the Vector holding attributes is changed to hold RefPtrs to attributes instead. This might change when attribute storage is implemented according to the spec (by way of NamedNodeMap).
2021-10-17LibJS: Convert to_double() to ThrowCompletionOrIdan Horowitz
2021-10-17LibWeb: Convert ArrayFromVector wrapper to instead be sequence<T>Luke Wilde
This adds the ParamatizedType, as `Vector<String>` doesn't encode the full type information. It is a separate struct as you can't have `Vector<Type>` inside of `Type`. This also makes Type RefCounted because I had to make parse_type return a pointer to make dynamic casting work correctly. The reason I made it RefCounted instead of using a NonnullOwnPtr is because it causes compiler errors that I don't want to figure out right now.
2021-10-15LibUnicode: Use u16 for unique string indices instead of size_tTimothy Flynn
Typically size_t is used for indices, but we can take advantage of the knowledge that there is approximately only 46K unique strings in the generated UnicodeLocale.cpp file. Therefore, we can get away with using u16 to store indices. There is a VERIFY that will fail if we ever exceed the limits of u16. On x86_64 builds, this reduces libunicode.so from 9.2 MiB to 7.3 MiB. On i686 builds, this reduces libunicode.so from 3.9 MiB to 3.3 MiB. These savings are entirely in the .rodata section of the shared library.
2021-10-14LibWeb: Stub out a basic IntersectionObserver interfaceTimothy Flynn
Note there are a couple of type differences between the spec and the IDL file added in this commit. For example, we will need to support a type of Variant to handle spec types such as "(double or sequence<double>)". But for now, this allows web pages to construct an IntersectionObserver with any valid type.
2021-10-14LibWeb: Allow creating "any" types in IDL with integral default valuesTimothy Flynn
This enables defining "any" types in IDL files such as: any threshold = 0; This isn't able to parse decimal values yet.
2021-10-13LibUnicode: Generate enum/alias from-string methods without a HashMapTimothy Flynn
The *_from_string() and resolve_*_alias() generated methods are the last remaining users of HashMap in the LibUnicode generated files (read: the last methods not using compile-time structures). This converts these methods to use an array containing pairs of hash values to the desired lookup value. Because this code generation is the same between GenerateUnicodeData.cpp and GenerateUnicodeLocale.cpp, this adds a GeneratorUtil.h header to the LibUnicode generators to contain the method that generates the methods.
2021-10-13LibJS: Convert to_object() to ThrowCompletionOrLinus Groh
2021-10-13LibJS: Convert to_string() to ThrowCompletionOrLinus Groh
Also update get_function_name() to use ThrowCompletionOr, but this is not a standard AO and should be refactored out of existence eventually.
2021-10-11LibJS+LibWeb: Let WrapperGenerator deal with legacy_null_to_empty_stringLinus Groh
This concept is not present in ECMAScript, and it bothers me every time I see it. It's only used by WrapperGenerator, and even there only relevant in two places, so let's fully remove it from LibJS and use a simple ternary expression instead: cpp_name = js_name.is_null() && legacy_null_to_empty_string ? String::empty() : js_name.to_string(global_object);
2021-10-11LibWeb: Add support for the Promise<T> IDL type to WrapperGeneratorLinus Groh
This includes parsing parameterized types (foo<T>) as well as generating the appropriate code in generate_wrap_statement() and generate_to_cpp().
2021-10-11LibWeb: Initialize IDL `any` values without default value to undefinedLinus Groh
Previously this would generate the following code: JS::Value foo_value; if (!foo.is_undefined()) foo_value = foo; Which is dangerous as we're passing an empty value around, which could be exposed to user code again. This is fine with "= null", for which it also generates: else foo_value = JS::js_null(); So, in summary: a value of type `any`, not `required`, with no default value and no initializer from user code will now default to undefined instead of an empty value.
2021-10-11LibWeb: Replace heycam.github.io/webidl URLs with webidl.spec.whatwg.orgLinus Groh
Web IDL is now a WHATWG standard and the specification was moved accordingly: https://twitter.com/annevk/status/1445311275026821120 The old URLs now redirect, but let's use canonical ones.
2021-10-11LibWeb: Stub out a basic ResizeObserver interfaceAndreas Kling
This patch establishes scaffolding for the ResizeObserver API.
2021-10-11LibWeb: Stub out a basic Selection interfaceAndreas Kling
This patch establishes scaffolding for the Selection API.
2021-10-10LibUnicode: Generate and use unique locale-related alias stringsTimothy Flynn
Almost all of these are already in the unique string list.
2021-10-10LibUnicode: Generate and use unique subtag and complex alias stringsTimothy Flynn
2021-10-10LibUnicode: Generate and use unique list-format stringsTimothy Flynn
The list-format strings used for Intl.ListFormat are small, but quite heavily duplicated. For example, the string "{0}, {1}" appears 6,519 times. Generate unique strings for this data to avoid duplication.
2021-10-10LibUnicode: Generate and use a set of unique locale-related stringsTimothy Flynn
In the generated UnicodeLocale.cpp file, there are 296,408 strings for localizations of languages, territories, scripts, currencies & keywords. Of these, only 43,848 (14.8%) are actually unique, so there are quite a large number of duplicated strings. This generates a single compile-time array to store these strings. The arrays for the localizations now store an index into this single array rather than duplicating any strings.
2021-10-10LibUnicode: Skip unknown languages and territoriesTimothy Flynn
Some CLDR languages.json / territories.json files contain localizations for some lanuages/territories that are otherwise not present in the CLDR database. We already don't generate anything in UnicodeLocale.cpp for these anomalies, but this will stop us from even storing that data in the generator's memory. This doesn't affect the output of the generator, but will have an effect after an upcoming commit to unique-ify all of the strings in the CLDR.
2021-10-10LibUnicode: Stop generating large UnicodeData hash mapTimothy Flynn
The data in this hash map is now available by way of much smaller arrays and is now unused.
2021-10-10LibUnicode: Generate standalone compile-time array for combining classTimothy Flynn
2021-10-10LibUnicode: Generate standalone compile-time array for special casingTimothy Flynn
There are only 112 code points with special casing rules, so this array is quite small (compared to the size 34,626 UnicodeData hash map that is also storing this data). Removing all casing rules from UnicodeData will happen in a subsequent commit.
2021-10-10LibUnicode: Generate standalone compile-time arrays for simple casingTimothy Flynn
Currently, all casing information (simple and special) are stored in a compile-time array of size 34,626, then statically copied to a hash map at runtime. In an effort to reduce the resulting memory usage, store the simple casing rules in standalone compile-time arrays. The uppercase map is size 1,450 and the lowercase map is size 1,433. Any code point not in a map will implicitly have an identity mapping.
2021-10-04LibWeb: Make IDL-constructed objects aware of their JS wrapperAndreas Kling
Having IDL constructors call FooWrapper::create(impl) directly was creating a wrapper directly without telling the impl object about the wrapper. This meant that we had wrapped C++ objects with a null wrapper() pointer.
2021-10-04LibJS: Convert ordinary_set_with_own_descriptor() to ThrowCompletionOrLinus Groh
2021-10-03LibJS: Convert has_own_property() to ThrowCompletionOrLinus Groh
2021-10-03LibJS: Convert create_data_property() to ThrowCompletionOrLinus Groh