| Age | Commit message (Collapse) | Author |
|---|
|
This AO can't throw so its optional is never empty.
|
|
|
|
|
|
This reverts commit 23febbed41d8296cf9e532a17145822cd099b591.
It breaks the TestTLSHandshake test used in CI, it causes it
to hang, and all CI jobs have been hanging.
|
|
Clang was failing because because it rightfully saw we were attempting
to call a deleted constructor of `MarkedValueList`. If you explicitly
called move(list) then GCC would complain that the move was unnecessary.
For what ever reason both tool chains accept when we construct the
ThrowCompletionOr explicitly that we move the list into and return that.
|
|
Some pages use *really* large data URLs. :^)
|
|
This was showing up as hot in profiles, as the HTML parser calls it
quite a lot.
|
|
|
|
Also add spec step comments to it while we're here.
|
|
|
|
Also add spec step comments to it as well as a missing exception check
while we're here.
|
|
Also add spec step comments to it while we're here.
|
|
|
|
We decided that we want to move away from throwing exceptions in AOs
and regular functions implicitly and then returning some
default-constructed value (usually an empty JS::Value) - this requires
remembering to check for an exception at the call site, which is
error-prone. It's also awkward for return values that cannot be
default-constructed, e.g. MarkedValueList.
Instead, the thrown value should be part of the function return value.
The solution to this is moving closer to the spec and using something
they call "completion records":
https://tc39.es/ecma262/#sec-completion-record-specification-type
This has various advantages:
- It becomes crystal clear whether some AO can fail or not, and errors
need to be handled and values unwrapped explicitly (for that reason
compatibility with the TRY() macro is already built-in, and a similar
TRY_OR_DISCARD() macro has been added specifically for use in LibJS,
while the majority of functions doesn't return ThrowCompletionOr yet)
- We no longer need to mix "valid" and "invalid" values of various types
for the success and exception outcomes (e.g. null/non-null AK::String,
empty/non-empty JS::Value)
- Subsequently it's no longer possible to accidentally use an exception
outcome return value as a success outcome return value (e.g. any AO
that returns a numeric type would return 0 even after throwing an
exception, at least before we started making use of Optional for that)
- Eventually the VM will no longer need to store an exception, and
temporarily clearing an exception (e.g. to call a function) becomes
obsolete - instead, completions will simply propagate up to the caller
outside of LibJS, which then can deal with it in any way
- Similar to throw we'll be able to implement the functionality of
break, continue, and return using completions, which will lead to
easier to understand code and fewer workarounds - the current
unwinding mechanism is not even remotely similar to the spec's
approach
The spec's NormalCompletion and ThrowCompletion AOs have been
implemented as simple wrappers around the JS::Completion constructor.
UpdateEmpty has been implemented as a JS::Completion method.
There's also a new VM::throw_completion<T>() helper, which basically
works like VM::throw_exception<T>() - it creates a T object (usually a
JS::Error), and returns it wrapped in a JS::Completion of Type::Throw.
Two temporary usage patterns have emerged:
1. Callee already returns ThrowCompletionOr, but caller doesn't:
auto foo = TRY_OR_DISCARD(bar());
2. Caller already returns ThrowCompletionOr, but callee doesn't:
auto foo = bar();
if (auto* exception = vm.exception())
return throw_completion(exception->value());
Eventually all error handling and unwrapping can be done with just TRY()
or possibly even operator? in the future :^)
Co-authored-by: Andreas Kling <kling@serenityos.org>
|
|
"result" is a tad bit too generic to provide a clash-free experience -
we found instances in LibJS where this breaks already. Essentially this
doesn't work:
auto foo = TRY(bar(result));
Because it expands to the following within the TRY() scope:
{
auto result = bar(result);
...
}
And that of course fails:
error: use of ‘result’ before deduction of ‘auto’
The simple solution here is to use a name that is much less likely to
clash with anything used in the expression ("_temporary_result"). :^)
|
|
There's no reason to limit ourselves to 4KiB, this socket is not
blocking anyway.
|
|
There's no reason to keep waiting when there's nothing else to come.
This makes RequestServer not spin on Core::Socket::read() (in some
scenarios).
|
|
Auto is not specified at all.
|
|
There probably are a lot of edge cases missing but this moves us forward
at least a bit.
|
|
|
|
This teaches all the relevant places about 'align-items'.
|
|
|
|
Avoid an unnecessary NonnullRefPtr<OpenFileDescription> copy.
|
|
These instructions now generate cubic Bézier curves.
|
|
This is pretty unsophisticated as it will simply add a fixed number of
of line segments approximating the curve. Still better than nothing.
|
|
- linear_interpolate
- quadratic_interpolate
- cubic_interpolate
|
|
|
|
This is much more common across the whole codebase and even these two
files. The same is used to return an empty JS::Value in an exception
check, for example.
|
|
|
|
Before, this was getting included as part of the output text, which was
confusing the HTML parser. Nobody needs the BOM after we have identified
the codec, so now we remove it when converting to UTF-8.
|
|
Extra configure options may need passed to CLion in order for it not to
choke on the new CMake setup. In particular, it's now a very bad idea to
pass CMAKE_CXX_COMPILER and CMAKE_C_COMPILER to the target build.
|
|
Now that we're generating the CMake toolchain file in the build
directory, we need to redirect the ports that use CMake to the new
location. Looking into this showed that there's still a bunch of work to
do in general to make the ports agnostic to which toolchain they're
using, there's a lot of hard-coded ${ARCH}-pc-serenity-gcc assumptions
still here.
|
|
The "CMAKE_<foo>" variable namespace is reserved, and CXXFILT is not
currently a variable known to upstream CMake.
|
|
This is really the business of the consuming project. We will need to
make changes to libjs-test262 and to oss-fuzz to address this properly.
|
|
Add additional clarification for the CMake cache, and add missing extra
targets as well.
|
|
Direct build commands to the SuperBuild's binary directory, and
image/run commands to the Serenity binary directory.
As a side benefit, make the lagom target only build Lagom instead of the
entire OS alongside Lagom.
|
|
Replace the old logic where we would start with a host build, and swap
all the CMake compiler and target variables underneath it to trick
CMake into building for Serenity after we configured and built the Lagom
code generators.
The SuperBuild creates two ExternalProjects, one for Lagom and one for
Serenity. The Serenity project depends on the install stage for the
Lagom build. The SuperBuild also generates a CMakeToolchain file for the
Serenity build to use that replaces the old toolchain file that was only
used for Ports.
To ensure that code generators are rebuilt when core libraries such as
AK and LibCore are modified, developers will need to direct their manual
`ninja` invocations to the SuperBuild's binary directory instead of the
Serenity binary directory.
This commit includes warning coalescing and option style cleanup for the
affected CMakeLists in the Kernel, top level, and runtime support
libraries. A large part of the cleanup is replacing USE_CLANG_TOOLCHAIN
with the proper CMAKE_CXX_COMPILER_ID variable, which will no longer be
confused by a host clang compiler.
|
|
This common strategy of having a serenity_option() macro defined in
either the Lagom or top level CMakeLists.txt allows us to do two things:
First, we can more clearly see which options are Serenity-specific,
Lagom-specific, or common between the target and host builds.
Second, it enables the upcoming SuperBuild changes to set() the options
in the SuperBuild's CMake cache and forward each target's options to the
corresponding ExternalProject.
|
|
This makes it so we don't need to specify the full path to all the
helper scripts we include() from different places in the codebase and
feels a lot cleaner.
|
|
This will be required when we switch to a SuperBuild that has Lagom as
a configure time dependency, but is a distinct enough change to be
separate.
|
|
This lets us possibly share downloaded artifacts between different
builds without re-downloading them every time you change toolchains.
|
|
We'll use this to prevent repeating common tool dependencies. They all
depend on LibCore and AK only. We also want to encapsulate common
install rules for them.
|
|
Tag key changes with fallthrough statement to document the intention.
|
|
This change will make the player able to control the game with
A and D keys, in addition to the current arrow keys and mouse.
|
|
In the past, the base class implementation of this was used to descend
into subtrees and paint children. That is now taken care of by
StackingContext::paint_descendants() instead, and nothing used this.
|
|
Computing the absolute rect of a box requires walking the chain of
containing blocks and apply any offsets encountered. This can be slow in
deeply nested box trees, so let's at least avoid doing it multiple times
when once is enough.
|
|
|
|
Previously, out-of-flow children still took up space inside a flex-box
container, leaving an odd gap. Now they don't! :^)
|
|
In some situations, a layout box should not participate in the standard
layout process, for example when set to `position: absolute`.
|
|
Specifically, this is to help fix a bug with `position: absolute`
children of a flex-box still taking up space, when they should not.
|
