This release brings support for various C++23 constructs like `if
consteval` and multidimensional subscript operators. Vectorization is
now enabled for O2 too, and `-ftrivial-auto-var-init` has been added
which can help us find and prevent security issues coming from
uninitialized variables.
Toolchain/Patches/gcc.patch is now significanly smaller as some unused,
autoconf-generated code has been removed.
Most of the string.h and wchar.h functions are implemented quite naively
at the moment, and GCC's pattern recognition pass might realize what we
are trying to do, and transform them into libcalls. This is usually a
useful optimization, but not when we're implementing the functions
themselves :^)
Relevant discussion from the GCC Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
This prevents the infamous recursive `strlen`.
A more proper fix would be writing these functions in assembly. That
would likely give a small performance boost as well ;)
The compiler would complain about `__builtin_memcpy` in ByteBuffer::copy
writing out of bounds, as it isn't able to deduce the invariant that the
inline buffer is only used when the requested size is smaller than the
inline capacity.
The other change is more bizarre. If the destructor's declaration
exists, gcc complains about a `delete` operation causing an
out-of-bounds array access.
error: array subscript 'DHCPv4Client::__as_base [0]' is partly outside
array bounds of 'unsigned char [8]' [-Werror=array-bounds]
14 | ~DHCPv4Client() = default;
| ^
This looks like a compiler bug, and I'll report it if I find a suitable
reduced reproducer.
I'm not even sure why this worked. How would the compiler know which
type to destruct the FilterInfo object as?
Fixes this janky error from gcc 12:
AK/RefCounted.h:70:13: error: array subscript 0 is outside array bounds
of 'void [56]' [-Werror=array-bounds]
70 | delete static_cast<const T*>(this);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Previously, if you opened MouseSettings, set the cursor theme to Dark,
and then click "Defaults", the cursors list would not update.
ComboBox::set_text() does not call the on_change callback, so we have
to run the steps manually.
I've also made `m_theme_name` into a local variable, since it can be.
When user code requests the current cursor theme name with
`GUI::ConnectionToWindowServer::the().get_cursor_theme()`, that reads
the name from the config file. If we don't write that out when it's
changed, then users get given an outdated cursor theme instead of the
current one.
In particular, changing the theme in MouseSettings, saving and closing
it, then reopening MouseSettings, would show the wrong theme selected.
So, that's fixed now. :^)
SettingsWindow now notices if the window is marked as modified, and
shows a confirmation pop-up to check if the user wants to apply or
discard their changes. It automatically marks the window as unmodified
after restoring defaults or applying the changes, but each Tab subclass
needs to call `set_modified(true)` when the user modifies things.
The "Apply" button is automatically disabled when there are no unsaved
changes to be applied.
This is the only Widget that ran its callback in deferred_invoke(). It
seems to be a holdover from when syntax-highlighting ran whenever the
text changed, but that has not been true since
bec2b3086c. Running the callback
immediately has no obvious downsides, but does make it a lot easier to
reason about. (I might have spent an hour confused as to why things
were happening in the wrong order...)
This commit implements glClipPlane and its supporting calls, backed
by new support for user-defined clip planes in the software GPU clipper.
This fixes some visual bugs seen in the Quake III port, in which mirrors
would only reflect correctly from close distances.
Now, when windows flash, the "active" color of the window title frame's
flash is the highlight color instead of the standard window color. The
"inactive" color of the flash is still the disabled color as before.
Reasoning behind this change in aesthetics: There are four [1] window
title frame colors with specific UI purposes:
1. "Active" for the normal active window, obvious purpose.
2. "Moving" for the window that is being dragged or resized by the user.
Responsible for acting as a visual click feedback as a kind of
subdued button.
3. "Inactive" for any inactive windows, obvious purpose.
4. "Highlight".
The purpose of "Highlight" is in the name, though it's non-obvious what
that exactly entails. Before, only alt-tab selecting windows would use
the highlight color for showing the current target window. In my opinion
this points to the purpose of "highlight" being to move the user's focus
to another window when the simple active state is not enough. Then it
makes sense to have the window flashing use the highlight color. The
entire purpose of window flashing is to shift the user's focus to a
dialog window that might not be close to the window they just clicked.
Using the highlight color enables an even stronger emphasis than before.
It enables a cleaner separation between the purpose of the two frame
colors, as well as making the "Highlight" frame more common.
[1] Technically there are eight, as the title frame has a gradient by
default. We can count the gradient as one color for this purpose.
According to the OpenGL spec, we're expected to clamp the fragment
depth values to the range `0.f - 1.f` for all polygons.
This fixes Z-fighting issues with the sky in Quake 3.
- Delete the part about removing `[Exposed=Window]` since that's not
necessary and we may want that information there to generate the
Window object.
- Mention adding `#import`s.
- Outline the requirements for the implementation class.
- Mention the non-Event wrapper factories that need to know about
certain types.
I tend to refer to this document every time I add an IDL type so it's
helpful if it's comprehensive.
Both of these are supposed to be set when the CSSRule is created. The
spec is silent on setting it when a CSSRule is added to a parent. So,
this is a bit ad-hoc.
The parent rule gets set whenever a rule is added to a new parent. The
parent stylesheet gets set whenever the rule or one of its ancestors is
added to a different stylesheet. There may be some nuance there that
I'm missing, but I'm sure we'll find out quickly once we have WPT
running!
The spec is a little bizarre here. One caller of this
(`CSSStyleSheet::insert_rule()`) wants to give it a parsed CSSRule, but
the spec itself wants it to take a string. (As will be used by
`CSSGroupingRule::insert_rule()`) Using a Variant isn't pretty but it's
the best solution I've come to - having two overloads was worse, whether
one called the other or they just duplicated the logic. This seems the
least bad.
