Multiboot only supports ELF32 executables. This changes the build
process to build an ELF32 executable which has a 32-bit entry point,
but consists of mostly 64-bit code.
Adds support for the :active pseudo-class for hyperlinks (<a> tags
only).
Also, since it was very similar to :focus and an element having a
focused state was already implemented, I went ahead and implemented
that pseudo-class too, although I cannot come up with a working
example to validate it.
This patch adds the alternate_shortcut member to LibGUI::Action, which
enables one Action to have two keyboard shortcuts.
Note that the string used in menus and tooltips only shows the main
shortcut, which is the same behaviour as in Firefox and Chrome.
At the moment these environments are always the same as the lexical
ones, so this didn't cause any trouble. Once we start separating them
we have to make sure both environments are protected.
This matches what ECMAScript calls it. Also make it a JS::Function*
instead of a generic Value, since it will always either be a function
object or null.
Since `m_storage` is already guaranteed to be correctly aligned for the
type, we can forgo specifying it for the entire class.
This fixes an error: previously, this would *force* the value type's
alignment on the entire class, which would try to make 1-byte aligned
ints with `KResultOr<bool>`. GCC somehow compiled this (probably just
ignored it), but this caused a build error with Clang.
Closes#8072
Since strings don't have a constexpr constructor, these won't have any
effect anyways. Furthermore, this is explicitly disallowed by the
standard, and makes Clang tools freak out.
Clang requires that attributes declared using the bracketed
`[[attr_name]]` syntax come before those with
`__attribute__((attr-name))`.
This fixes a Clang build error.
Clang enforces the ordering that attributes specified with the
`[[attr_name]]` syntax must comes before those defines as
`__attribute__((attr_name))`. We don't want to deal with that, so we
should stick to a single syntax (for functions, at least).
This commit favors the latter, as it's used more widely in the code
(for declaring more "exotic" options), and changing those would be a
larger effort than modifying this single file.
This commit converts naked `new`s to `AK::try_make` and `AK::try_create`
wherever possible. If the called constructor is private, this can not be
done, so we instead now use the standard-defined and compiler-agnostic
`new (nothrow)`.
These functions abstract away the need to call the proper new operator
("throwing" or "non-throwing") and manually adopt the resulting raw
pointer. Modelled after the existing `NonnullOwnPtr<T> make()`
functions, these forward their parameters to the object's constructor.
Note: These can't be used in the common "factory method" idiom, as
private constructors can't be called from a standalone function.
The naming is consistent with AK's and Shell's previous implementation
of these:
- `make` creates a `NonnullOwnPtr<T>` and aborts if the allocation could
not be performed.
- `try_make` creates an `OwnPtr<T>`, which may be null if the allocation
failed.
- `create` creates a `NonnullRefPtr<T>`, and aborts on allocation
failure.
- `try_create` creates a `RefPtr<T>`, which may be null if the
allocation was not successful.
In standard C++, operators `new` and `new[]` are guaranteed to return a
valid (non-null) pointer and throw an exception if the allocation
couldn't be performed. Based on this, compilers did not check the
returned pointer before attempting to use them for object construction.
To avoid this, the allocator operators were changed to be `noexcept` in
PR #7026, which made GCC emit the desired null checks. Unfortunately,
this is a non-standard feature which meant that Clang would not accept
these function definitions, as it did not match its expected
declaration.
To make compiling using Clang possible, the special "nothrow" versions
of `new` are implemented in this commit. These take a tag type of
`std::nothrow_t` (used for disambiguating from placement new/etc.), and
are allowed by the standard to return null. There is a global variable,
`std::nothrow`, declared with this type, which is also exported into the
global namespace.
To perform fallible allocations, the following syntax should be used:
```cpp
auto ptr = new (nothrow) T;
```
As we don't support exceptions in the kernel, the only way of uphold the
"throwing" new's guarantee is to abort if the allocation couldn't be
performed. Once we have proper OOM handling in the kernel, this should
only be used for critical allocations, where we wouldn't be able to
recover from allocation failures anyway.
While Clang claims to implement GCC's atomics libcall API, a small
incompatibility caused our builds to fail on Clang.
Clang requires requires the operands to its fixed-size functions to be
integer types, while GCC will take any type with the same size and
alignment as the various integer primitives. This was problematic, as
atomic `enum class`es would not compile.
Furthermore, Clang does not like if only one operand pointer is marked
volatile. Because it only affects the standalone atomic functions, that
will be fixed in a later commit.
As an added benefit, the code is more type-safe, as it won't let us
perform arithmetic on non-integer types. Types with overloaded
arithmetic types won't cause unexpected behavior anymore.
The constructors for the various atomic types can now be used in
constant expressions.
Previously the remove home directory option never actually removed the
user's home directory because it was not properly unveiled. By
validating the user with Core::Account, we can identify the user's home
directory earlier in the program and unveil as necessary.
Additionally, by identifying if the user does not exist much earlier in
the program, this elimates depending on getpwent to validate the user
and creating unneccessary temp files.
This is true for environments created by `with` statements, and false
for other (global) object environments.
Also add the WithBaseObject abstract operation while we're here.
Scoring is designed to mimic Microsoft's implementation - starting at
500, decreasing by 1 every move, and increasing by 100 for every full
stack.
Fixes GH-5319.
This introduces a new MovementType concept to LibCards, starting the
process to allow other patience games to be implemented using it - that
differ more substantially from Klondike in logic.
This is currently used for two purposes: 1. to verify that the
'grabbed' stack of cards is valid* (sequential and correct colours) and
2. to allow 'grabbed' stacks to be pushed onto same-colour,
either-colour, or alternating-colour stacks
* Klondike doesn't need this logic, as per how the game works any
'grabbed' selection is guaranteed to be valid.
This rewrites the dbgputch and dbgputstr system calls as wrappers of
kstdio.h.
This fixes a bug where only the Kernel's debug output was also sent to
a serial debugger, while the userspace's debug output was only sent to
the Bochs debugger.
This also fixes a bug where debug output from one process would
sometimes "interrupt" the debug output from another process in the
middle of a line.
This adds a dbgputch() alongside dbgputstr() in kstdio.h. The function
already existed as the static function debugger_out(). It has now been
exposed to users of kstdio.h.
This adds just enough stubs to make the kernel compile on x86_64. Obviously
it won't do anything useful - in fact it won't even attempt to boot because
Multiboot doesn't support ELF64 binaries - but it gets those compiler errors
out of the way so more progress can be made getting all the missing
functionality in place.
When constructing values of the InstructionData type we assume that
the event_count field is a size_t while it actually is a u32. On x86_64
this fails because those are different types.