| Age | Commit message (Collapse) | Author |
|---|
|
Note that js_rope_string() has been folded into this, the old name was
misleading - it would not always create a rope string, only if both
sides are not empty strings. Use a three-argument create() overload
instead.
|
|
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
|
|
|
|
This means it no longer is locale dependent and doesn't incorrectly
accept hex floats anymore.
|
|
Now that we have OS macros for essentially every supported OS, let's try
to use them everywhere.
|
|
In particular, StringView::contains(char) is often used with a u32
code point. When this is done, the compiler will for some reason allow
data corruption to occur silently.
In fact, this is one of two reasons for the following OSS Fuzz issue:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49184
This is probably a very old bug.
In the particular case of URLParser, AK::is_url_code_point got confused:
return /* ... */ || "!$&'()*+,-./:;=?@_~"sv.contains(code_point);
If code_point is a large code point that happens to have the correct
lower bytes, AK::is_url_code_point is then convinced that the given
code point is okay, even if it is actually problematic.
This commit fixes *only* the silent data corruption due to the erroneous
conversion, and does not fully resolve OSS-Fuzz#49184.
|
|
Instead of hardcoding all the property definitions in GlobalObject's
initialize() function, make it the standalone AO it is supposed to be
that can then be used by other global objects that don't inherit from
JS::GlobalObject.
|
|
This will later allow global objects not inheriting from the regular
JS::GlobalObject to pull in these functions without having to implement
them from scratch. The primary use case here is, again, a wrapper-less
HTML::Window in LibWeb :^)
Allocating these upfront now allows us to get rid of two hacks:
- The GlobalObject assigning Intrinsics private members after finishing
its initialization
- The GlobalObject defining the parseInt and parseFloat properties of
the NumberConstructor object, as they are supposed to be identical
with the global functions of the same name
|
|
There's nothing special about global object initialization anymore, this
can just work the same way as for any other object now.
|
|
GlobalObject is now a regular object with no special properties :^)
|
|
This will allow us to move the underlying console from GlobalObject to
ConsoleObject without still having to do a 'console' property lookup on
the GlobalObject.
|
|
This was not being used for anything meaningful, just store a reference
to the VM directly.
|
|
|
|
Intrinsics, i.e. mostly constructor and prototype objects, but also
things like empty and new object shape now live on a new heap-allocated
JS::Intrinsics object, thus completing the long journey of taking all
the magic away from the global object.
This represents the Realm's [[Intrinsics]] slot in the spec and matches
its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of
architecture.
In the majority of cases it should now be possibly to fully allocate a
regular object without the global object existing, and in fact that's
what we do now - the realm is allocated before the global object, and
the intrinsics between both :^)
|
|
This is needed so that the allocated NativeFunction receives the correct
realm, usually forwarded from the Object's initialize() function, rather
than using the current realm.
|
|
Global object initialization is tightly coupled to realm creation, so
simply pass it to the function instead of relying on the non-standard
'associated realm' concept, which I'd like to remove later.
This works essentially the same way as regular Object::initialize() now.
Additionally this allows us to forward the realm to GlobalObject's
add_constructor() / initialize_constructor() helpers, so they set the
correct realm on the allocated constructor function object.
|
|
|
|
|
|
|
|
|
|
This is where the fun begins. :^)
|
|
This is a continuation of the previous five commits.
A first big step into the direction of no longer having to pass a realm
(or currently, a global object) trough layers upon layers of AOs!
Unlike the create() APIs we can safely assume that this is only ever
called when a running execution context and therefore current realm
exists. If not, you can always manually allocate the Error and put it in
a Completion :^)
In the spec, throw exceptions implicitly use the current realm's
intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
|
|
This is a continuation of the previous three commits.
Now that create() receives the allocating realm, we can simply forward
that to allocate(), which accounts for the majority of these changes.
Additionally, we can get rid of the realm_from_global_object() in one
place, with one more remaining in VM::throw_completion().
|
|
This is a continuation of the previous two commits.
As allocating a JS cell already primarily involves a realm instead of a
global object, and we'll need to pass one to the allocate() function
itself eventually (it's bridged via the global object right now), the
create() functions need to receive a realm as well.
The plan is for this to be the highest-level function that actually
receives a realm and passes it around, AOs on an even higher level will
use the "current realm" concept via VM::current_realm() as that's what
the spec assumes; passing around realms (or global objects, for that
matter) on higher AO levels is pointless and unlike for allocating
individual objects, which may happen outside of regular JS execution, we
don't need control over the specific realm that is being used there.
|
|
This is a continuation of the previous commit.
Calling initialize() is the first thing that's done after allocating a
cell on the JS heap - and in the common case of allocating an object,
that's where properties are assigned and intrinsics occasionally
accessed.
Since those are supposed to live on the realm eventually, this is
another step into that direction.
|
|
No functional changes - we can still very easily get to the global
object via `Realm::global_object()`. This is in preparation of moving
the intrinsics to the realm and no longer having to pass a global
object when allocating any object.
In a few (now, and many more in subsequent commits) places we get a
realm using `GlobalObject::associated_realm()`, this is intended to be
temporary. For example, create() functions will later receive the same
treatment and are passed a realm instead of a global object.
|
|
This is a cautious first step towards being able to create JS objects
before a global object has been instantiated.
|
|
|
|
This is a normative change in the ecma262 spec.
See: https://github.com/tc39/ecma262/commit/2527be4
|
|
Not implementing any prototype functions yet, but stubbing out async
generator infrastructure will allow us to make some progress in that
direction.
|
|
This is an editorial change in the ECMA-262 spec.
See: https://github.com/tc39/ecma262/commit/33ea99e
|
|
This is an editorial change in the ECMA-262 spec, with similar changes
in some proposals.
See:
- https://github.com/tc39/ecma262/commit/7575f74
- https://github.com/tc39/proposal-array-grouping/commit/df899eb
- https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12
- https://github.com/tc39/proposal-shadowrealm/commit/c81f527
|
|
The existing code looks innocently correct, implementing the following
step:
3. If IsCallable(func) is false, set func to the intrinsic function
%Object.prototype.toString%.
as
return ObjectPrototype::to_string(vm, global_object);
However, this misses the fact that the next step calls the function with
the previously ToObject()'d this value (`array`):
4. Return ? Call(func, array).
This doesn't happen in the current implementation, which will use the
unaltered this value from the Array.prototype.toString() call, and make
another, unequal object in %Object.prototype.toString%. Since both that
and Array.prototype.toString() do a Get() call on said object, this
behavior is observable (see newly added test).
Fix this by actually doing what the spec says and calling the fallback
function the regular way.
|
|
|
|
|
|
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."
|
|
We were previously manually initializing them instead of just calling
GlobalObject::initialize_constructor, which aside from duplicating code
also meant we didn't set the required name property.
|
|
|
|
|
|
|
|
This will allow us to safely call it if we need to parse JSON within
LibJS.
|
|
This prevents random crashes in for async loops due to GC.
|
|
This adds plumbing for the Intl.Collator object, constructor, and
prototype.
|
|
This adds plumbing for the Intl.PluralRules object, constructor, and
prototype.
|
|
This adds plumbing for the Intl.RelativeTimeFormat object, constructor,
and prototype.
|
|
We also forgot to allocate an AsyncFunctionConstructor and assign it to
m_async_function_constructor during GlobalObject initialization, whoops!
|
|
|
|
|
|
|
|
As required by the specification:
7. If Octets does not contain a valid UTF-8 encoding of a Unicode code
point, throw a URIError exception.
|
