This rule attempts to flag invisible Unicode characters which would
potentially be used by an attacker to hide code that humans can't see.
https://pvs-studio.com/en/docs/warnings/v1076/
AKA the "Trojan Source" attack: https://arxiv.org/abs/2111.00169
Unfortunately our `LibUnicode` source code contains these hidden
characters as they are part of the Unicode character set that the
library exposes. So we have, and will always have 100s of false
positives.
To include Serenity's LibJS on test262.report, we will need to integrate
with esvu. Create a .tar.gz with js(1) binary and the Lagom libraries it
it needs to run, and upload that package as a build artifact.
Since the build now happens in Build/$SERENITY_ARCH/ and not in Build/,
this updates check-symbols.sh to use the correct directory to check the
LibC symbols in. For some reason, the constant failures did not show
up as errors in CI.
In the last few commits, a second patch was added to the LLVM toolchain,
and it no longer uses our binutils patch. This commit changes the CI
cache keys accordingly, in order to prevent unnecessary rebuilds of both
toolchains when only one is changed.
The Clang toolchain's cache now only takes into account patches that
begin with `llvm`, and the GNU toolchain excludes those from the hash
calculation. We now also hash the two CMake cache files that we use for
building LLVM and its runtime libraries.
We often see PR's opened and then immediately closed because folks think
they did something bad, or don't know how to fix the situation. So lets
try to give them a few pointers.
We didn't initially upgrade because it started to (incorrectly) see
files as strict mode and chokes on things that then would be syntax
errors - but we're starting to fall behind a bit, so I'd rather put
these files on the ignore list instead.
Previously if a commit message contained any carriage returns it would
correctly fail the 'contains CRLF line breaks' test, but it would also
report 'Commit message lines are too long' and 'Commit title ends in a
period', even if neither is true.
This rule appears to produce a lot of noise, most of them look like
false positives (400+). Lets suppress for now to try to move the signal
to noise ratio higher for PVS-Studio.
Reference: https://pvs-studio.com/en/docs/warnings/v1047/
tim-actions/commit-message-checker-with-regex@v0.3.1 only uses the
keys 'sha' and 'commit.message'. Passing more information than that
is unnecessary and can lead to CI failures like this one:
https://github.com/SerenityOS/serenity/runs/4029269017?check_suite_focus=true#step:4:7
Instead of trying to pass data between workflow steps, we can instead
just do it all at once (plus this gives us more control over
formatting, which has also been improved).
'bootmode' now only controls which set of services are started by
SystemServer, so it is more appropriate to rename it to system_mode, and
no longer validate it in the Kernel.
Bootmode used to control framebuffers, panic behavior, and SystemServer.
This patch factors framebuffer control into a separate flag.
Note that the combination 'bootmode=self-test fbdev=on' leads to
unexpected behavior, which can only be fixed in a later commit.
Much like the sonar cloud workflow, this workflow runs pvs-studio
static analysis, and uploads the SARIF results to github. This
is the most "convenient" way to publish results, but unfortunately
users need write access to the repository to reach static analysis
results rendered in github.
As a work around folks can just look at the logs where issues are
printed during analysis, this works reasonably well.
In the future it might make sense to also render the results as HTML
and publish them using github page, much like we do with man pages.
I believe the pvs-studio plog-converter tool supports that as well.
https://pvs-studio.com/en/docs/manual/0036/
We need to exclude this file from analysis for now, as there is a bug in
the sonar-runner tool where it crashes when trying to understand the use
of AK::Variant in LibWasm/Parser/Parser.cpp
See #10122 for details + link to the bug report to Sonar Cloud.
I was experimenting with using caching while doing the initial prototype
of the Sonar Cloud workflow. However the cache size for the static
analysis data ended up being large enough that it would put us over the
git hub actions limit. Given that we currently only run this pipeline
once a day, it seems reasonable to just remove caching.
If in the future we decide to run the pipeline on every PR, caching
would become crucial as the current un-cached analysis time is around
1 hour and 50 minutes. If we did this we would need to move the pipeline
to Azure DevOps where we have effectively infinite cache available.
This requires exposing the `configure` step on the `serenity`
ExternalProject in the SuperBuild CMakeLists so that we can continue to
only build the generated sources and not the entire OS.
Replace the old logic where we would start with a host build, and swap
all the CMake compiler and target variables underneath it to trick
CMake into building for Serenity after we configured and built the Lagom
code generators.
The SuperBuild creates two ExternalProjects, one for Lagom and one for
Serenity. The Serenity project depends on the install stage for the
Lagom build. The SuperBuild also generates a CMakeToolchain file for the
Serenity build to use that replaces the old toolchain file that was only
used for Ports.
To ensure that code generators are rebuilt when core libraries such as
AK and LibCore are modified, developers will need to direct their manual
`ninja` invocations to the SuperBuild's binary directory instead of the
Serenity binary directory.
This commit includes warning coalescing and option style cleanup for the
affected CMakeLists in the Kernel, top level, and runtime support
libraries. A large part of the cleanup is replacing USE_CLANG_TOOLCHAIN
with the proper CMAKE_CXX_COMPILER_ID variable, which will no longer be
confused by a host clang compiler.
This commit snuck into the tree via a PR for some sonar cloud fixes.
Some how I cross contaminated my branches.
Unfortunately the coverity workflow isn't ready for prime time yet,
so lets remove it until we have all the issues ironed out.
The matrix variables were left over from copy/pasting the contents
of the normal CI workflow. We also should always skip saving the
cache, as the normal CI pipeliens will refresh the toolchain and
we should just be reading the cache.
