Make include-what-you-use happy with some files in source/lib and fix
what needs to be fixed.
Ref: #8086
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Make include-what-you-use happy with some files in source/renderer and
fix what needs to be fixed.
Ref: #8086
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
`JSNatives` passed to SpiderMonkey must not throw exceptions. Most
callbacks are wrapped in `ScriptFunction::ToJSNative`.
This commit adds exception handling to `ScriptFunction::ToJSNative` so
that exceptions thrown in the wrapped callbacks are catched and rethrown
as JavaScript `Error`s.
Make include-what-you-use happy with most of the files in source/gui and
fix what needs to be fixed after including missing compile flags.
Ref: #8086
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
During hotloading the `ScriptRequest` was constructed from a
`JSContext*`. That requires that already an other `ScriptRequest` is
active. Which isn't always the case.
Now The `ScriptRequest` is constructed from a `ScriptInterface&`.
Storing a `ScriptInterface&` in the `ModuleLoader::Result` allows to
remove the `m_Result` as it is retrieved from the `ScriptInterface`.
This commit introduces support for std::optional<T> in
Script::FromJSVal. When a JavaScript value is undefined or null, the
resulting optional is set to std::nullopt; otherwise, the value is
converted and wrapped.
This change allows components to cleanly handle optional script values
without needing manual null checks or exception handling in C++.
As a direct application of this feature, the Identity component now uses
std::optional<std::wstring> for the return value of GetCiv(). This
resolves a bug where formation templates (e.g., those inheriting from
template_formation.xml) do not explicitly define a civ. After commit
03f7903fec, the code assumed GetCiv() would always return a valid
string, leading to undefined behavior when it was missing.
With this update:
- GetCiv() returning undefined results in an empty optional.
- The Identity component defaults to an empty civilization string ("")
when the civ is not defined.
- This avoids crashes or actor parsing errors for civ-less templates and
improves robustness in script-C++ interaction.
Closes: #8107Fixes: #8091
Previously, if a JavaScript function returned a value that failed to
convert to the requested C++ type (e.g., from JS undefined to
std::wstring), the ScriptInterface would fail silently, making debugging
difficult.
This commit improves the error reporting in the script system by logging
the name of the JavaScript function being called when a type conversion
failure occurs. This makes it easier to trace and fix issues arising
from script-side inconsistencies or missing return values.
The improved logging is particularly useful for debugging errors such as
undefined civ values from GetCiv() when used via m_Script.Call<T>().
Add a way to tell whether `ReloadChangedFiles` actually catched events
by returning `INFO::SKIPPED` when it didn't.
Unlike GUI apps, you have to explicitely tell macOS to punp events in
console apps thus add a loop in the tests.
Not all modules should be able to load all other modules. A predicate
function can to be passed to the `ScriptInterface`. That function
returns whether the module is allowed to loat the module. If no
predicate is passed in no modules can be loaded through that
`ScriptInterface`.
- With modules JavaScript code can be split up into multiple files. We
already implemented such a mechanism (`Engine.LoadLibrary`) in
multiple parts of the engine. The advantage of using modules is
that it's standart (JS-devs are familiar with it) and it doesn't
has to be implemented multiple times.
Note that `Engine.LoadLibrary` loads all files in a directory
while the new `import` only loads one file.
- With modules seemingly global variables are local to that
script/module. We already implemented such a mechanism
(`ScriptInterface::LoadScript`).
As noted on #7979, we run into OOMs since commit af32d386b9. The reason is that the default incremental GC budget is unlimited, which actually doesn't perform incremental GCs. Our settings can lead to situation where the incremental GCs don't actually sweep, thus not freeing memory.
SM has a mechanism to avoid OOM anyways with LAST_DITCH GCs, but by default these can only occur ever 30 seconds. Turn this off.
Reported by: langbart
Shrinking GCs dump the JITted code, which leads to redundant recompilations, lowers performance, and makes profiling JS more difficult.
They may still happen if the runtime is at risk of OOM.
SpiderMonkey 98 introduced a size heuristic for the nursery GC region
(https://phabricator.services.mozilla.com/D136637). As this heuristic
uses a wall-clock time duration, it results in a severe performance
regression on slower systems for our use case.
This commit adds a workaround to turn off that heuristic, by telling
SpiderMonkey that a "page load" (something which doesn't have a meaning
in the context of pyrogenesis) is in progress, as that heuristic is
disabled for page loads.
Co-Authored by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Fixes#7714
The context option enabling strict mode was removed in sm-117 [1]
requiring to use the compiler option for the same purpose instead.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1621603
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
- Shallow-freezing of objects is never used in our codebase, so remove
that code path.
- Deep-freeze is bugged in recent versions of SpiderMonkey (see bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1930258). Until a fix
and/or a better API is provided, reimplement this feature by
recusively freezing object properties.
- Add tests for the deepfreeze function.
When calling `Engine.PushGuiPage` a promise is returned. The promise is
settled when the "child" page is closed. That allows to `await` it
inside `async` functions.
Previously the callback was run right inside the call to
`Engine.PopGuiPage`. Now the continuation of the promise is called at
the end of the "tick".
This won't help performance. It will more likely make things worse.
Since gui pages aren't opened or closed that frequently, it doesn't
matter that much.
Refs: 86c151ebaa
For the engine side:
The promise is stored in the `CGUIManager::SGUIPage` (like previously
the callback). When the promise is fulfilled it enqueues a callback in
the `JobQueue` of the `JSContext`.
Original patch by: @wraitii
Comments by: @wraitii, @Stan, @Polakrity, @lyv, @elexis, @vladislavbelov
Differential Revision: https://code.wildfiregames.com/D3807
This was SVN commit r28145.
This way it's clear what's the input and what's the output of the
computation.
All map generation scripts should reman working. They are adopted in a
future commit.
`Engine.SetProgress` and `Engine.ExportMap` can be removed in a future
commit.
Comments by: @marder, @sera, @Stan
Differential Revision: https://code.wildfiregames.com/D5220
This was SVN commit r28093.
The return-slot provided by the `Future` is used for synchronisation.
Refs: #5874
Comments By: @Stan, @vladislavbelov, @wraitii
Differential Revision: https://code.wildfiregames.com/D5001
This was SVN commit r27944.
