In the normal editing engine keys like Home, End etc work on visual
lines, but vim operates on real ones. Eg if you have a really long line
and wrapping is on then in normal editing Home would take you to the
beginning of the wrapped line, but 'I' would put you insert mode at the
beginning of the real line in vim.
This data structure is a much better fit for what is essentially a
sorted list of non-overlapping ranges.
Not using Vector means we no longer have to worry about Vector buffers
getting huge. Only nice & small allocations from now on.
Prior to this, it'd try to stuff them into an i64, which could fail and
give us nothing.
Even though this is an extension we've made to JSON, the parser should
be able to correctly round-trip from whatever our serialiser has
generated.
This fixes parsing the following regular expression: /</g;
It also adds a simple script element to the HTMLTokenizer regression
test, which also contains that specific regex.
Just like the previous Temporal.{Instant,TimeZone} commits, this patch
adds the Calendar object itself, its constructor and prototype
(currently empty), and two required abstract operations.
Note: this exact implementation is needed for __atomic_is_lock_free to
link with both GCC (for the SerenityOS build) and Clang (for the Fuzzer
build). The size argument must be a compile-time constant, otherwise it
fails to link with both compilers. Alternatively, the following
definition links with GCC but fails with Clang:
template<size_t S>
static inline bool atomic_is_lock_free(volatile void* ptr = nullptr)
{
return __atomic_is_lock_free(S, ptr);
}
This adds a new section .ksyms at the end of the linker map, reserves
5MiB for it (which are after end_of_kernel_image so they get re-used
once MemoryManager is initialized) and then embeds the symbol map into
the kernel binary with objcopy. This also shrinks the .ksyms section to
the real size of the symbol file (around 900KiB at the moment).
By doing this we can make the symbol map available much earlier in the
boot process, i.e. even before VFS is available.
The test suite includes a few basic tests and a very crude regression
test, which just concatenates the to_string() of all tokens and checks
the String's hash to be equal. This relies on the format of
HTMLToken::to_string() to stay the same, which is not ideal.
When repeatedly enqueing and dequeing a single item in a Queue we end
up faulting in all the pages for the underlying Vector. This is a
performance issue - especially where the element type is large.