serenity - The Serenity Operating System 🐞

Age	Commit message (Collapse)	Author
2022-08-29	LibJS: Hide all the constructors!	Andreas Kling
	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-29	LibJS: Add JS_CELL macro and use it in all JS::Cell subclasses	Andreas Kling
	This is similar to what we already had with JS_OBJECT (and also JS_ENVIRONMENT) but sits at the top of the Cell inheritance hierarchy.
2022-08-23	LibJS+LibWeb: Replace GlobalObject with Realm in create() functions	Linus Groh
	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.
2022-08-23	LibJS+LibWeb: Replace GlobalObject with Realm in initialize() functions	Linus Groh
	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.
2022-03-19	DevTools+LibJS+LibWeb: Change class_name to use StringView	Lenny Maiorani
	This helps make the overall codebase consistent. `class_name()` in `Kernel` is always `StringView`, but not elsewhere. Additionally, this results in the `strlen` (which needs to be done when printing or other operations) always being computed at compile-time.
2022-02-05	LibJS: Visit internal values in PromiseValueList	davidot

2022-01-31	Everywhere: Update copyrights with my new serenityos.org e-mail :^)	Timothy Flynn

2022-01-04	LibJS: Convert PromiseResolvingElementFunction to ThrowCompletionOr	Linus Groh

2021-10-21	LibJS: Convert NativeFunction::{call,construct}() to ThrowCompletionOr	Linus 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-09-11	LibJS: Specify right base for PromiseResolvingElementFunction subclasses	Andreas Kling

2021-09-11	LibJS: Don't use MarkedValueList in PromiseValueList	Andreas Kling
	Instead, override visit_edges() and mark the values like any other Cell subclass would. This makes PromiseValueList play nice with zombification.
2021-08-23	LibJS: Implement Promise.allSettled on the Promise constructor	Timothy Flynn

2021-08-23	LibJS: Implement Promise.any on the Promise constructor	Timothy Flynn

2021-08-23	LibJS: Generalize PromiseAllResolveElementFunction common functionality	Timothy Flynn
	The element-resolving functions on the Promise constructor are all very similar. To prepare for more of these functions to be implemented, break out common parts into a base class.