According to the Khronos group, GL enum values are in the spec:
https://www.khronos.org/registry/OpenGL/docs/enums.html
Not adhering to their values will cause issues with projects that ship
their own copy of `gl.h`, such as ScummVM.
This patch breaks FormattingContext::layout_inside() into two functions,
one that creates an independent formatting context (if needed), and
another that calls the former and then performs the inside layout within
the appropriate context.
The main goal here was to make layout_inside() return the independent
formatting context if one was created. This will allow us to defer
certain operations in child contexts until the parent context has
finished formatting the child root box.
d0fb511d75 set the maximized window value
in the File Manager before a window was created, which resulted in crash
everytime you tried to open the program that was closed while it was
maximized. ugh
Here we do more-or-less what GUI::Window::set_rect() does, except we
don't add it to the WindowServer::create_window() IPC call.
That's because the Window Server knows nothing about menus at this
point and just assumes they don't need to be visible.
So if we try to maximize the window then, it could be slightly taller
and a titlebar could be hidden.
So even though it looks how it looks like, it does work and it doesn't
show in the startup size, as described in the mentioned commit (the call
is put a few lines before the initial update()). :^)
Pro tip: If your function takes a StringBuilder by value, it doesn't
actually append anything to the caller's StringBuilder. On the plus
side, I probably won't make this mistake for a while? I hope?
This commit introduces the changes needed in the port build system that
will allow us to compile ports with Clang. Note that many ports still
don't build, especially due to linker differences. Fixing these is
outside the scope of this PR.
For now, building bash, ncurses and nano is known to work. Bash runs
fine, while nano crashes due to DT_VERSYM not being supported by our
dynamic loader.
By enabling LTO for the kernel_heap object too, we open the door for
optimization opportunities that come from (partially) inlining `::new`
or kmalloc. Every software spends a non-trivial amount of its run time
on allocating memory, so hopefully this change will make LTO builds even
faster.
This commit updates the Clang toolchain's version to 13.0.0, which comes
with better C++20 support and improved handling of new features by
clang-format. Due to the newly enabled `-Bsymbolic-functions` flag, our
Clang binaries will only be 2-4% slower than if we dynamically linked
them, but we save hundreds of megabytes of disk space.
The `BuildClang.sh` script has been reworked to build the entire
toolchain in just three steps: one for the compiler, one for GNU
binutils, and one for the runtime libraries. This reduces the complexity
of the build script, and will allow us to modify the CI configuration to
only rebuild the libraries when our libc headers change.
Most of the compile flags have been moved out to a separate CMake cache
file, similarly to how the Android and Fuchsia toolchains are
implemented within the LLVM repo. This provides a nicer interface than
the heaps of command-line arguments.
We no longer build separate toolchains for each architecture, as the
same Clang binary can compile code for multiple targets.
The horrible mess that `SERENITY_CLANG_ARCH` was, has been removed in
this commit. Clang happily accepts an `i686-pc-serenity` target triple,
which matches what our GCC toolchain accepts.
LLD fails to define the _GLOBAL_OFFSET_TABLE_ symbol if all inputs to it
are LLVM bitcode files (i.e. those used for LTO). To allow the kernel to
be built with ThinLTO, the workaround suggested in the original LLVM bug
report (<https://bugs.llvm.org/show_bug.cgi?id=39634>) is added in this
commit.
Previously we rejected all entries from Loader.so even if the faulting
address was located in it, i.e. the actual issue was with the dynamic
loader. We no longer do that to make debugging Loader crashes easier.
Our implementation (naively) assumes that there is a one-to-one
correspondence between compilation units and line programs, and that
their orders are identical. This is not the case for embedded resources,
as Clang only creates line programs for it, but not compilation units.
This mismatch caused an assertion failure, which made generating
backtraces for GUI applications impossible. This commit introduces a
hack that skips creating CompilationUnit objects for LinePrograms that
come from embedded resources.
These forms were introduced in DWARF5, and have a fair deal of
advantages over the more traditional encodings: they reduce the size of
the binary and the number of relocations.
GCC does not emit these with `-g1` by default, but Clang does at all
debug levels.
This will be needed when we add `DW_FORM_strx*` and `DW_FORM_addrx*`
support, which requires us to fetch `DW_AT_str_offsets_base` and
`DW_AT_addr_base` attributes from the parent compilation unit. This
can't be done as we read the values, because it would create infinite
recursion (as we might try to parse the compilation unit's
`DW_FORM_strx*` encoded name before we get to the attribute). Having
getters ensures that we will perform lookups if they are needed.
Our Clang toolchain uses versioned names for its shared libraries,
meaning that our applications link against `libc++.so.1.0`, not simply
`libc++.so`. Without this change, the LLVM runtime libraries are
excluded from backtraces, which makes debugging toolchain issues harder.
There is no need to have a user-defined copy constructor that simply
calls the base class's copy constructor. By having the compiler generate
it for us, Span is made trivially copyable, so it can be passed in
registers.
This allows the linker to link against these dynamic libraries when
compiling libc++/libunwind, without having to do a separate
bootstrapping LibC build.
Without this change, libc++ would fail to pick up the need to link to
`LibPthread` if no prior builds of it existed. Because of this, we'd
immediately have an assertion failure in SystemServer, as mutexes are
used for the safe construction of function-local static variables.
The `wcsxfrm` function copies a wide character string into a buffer,
such that comparing the new string against any similarly pre-processed
string with `wcscmp` produces the same result as if the original strings
were compared with `wcscoll`.
Our current `wcscoll` implementation is simply an alias for `wcscmp`, so
`wcsxfrm` needs to perform no actions other than copying the string.
The ELAST macro is used on many systems to refer to the largest possible
valid errno value. LLVM's libc++ uses errno values of ELAST+1 and
ELAST+2 internally, and defines an arbitrary fallback value for
platforms which don't have the macro. This means that it's possible for
their internal errno numbers could coincide with values we actually use,
which would be a very bad thing.
