This moves some stuff around to make LibGUI depend on LibSyntax instead
of the other way around, as not every application that wishes to do
syntax highlighting is necessarily a LibGUI (or even a GUI) application.
Function `CellSyntaxHighlighter::rehighlight()` direct inserted spans
to TextDocument `m_span` vector missing out important reordering and
merging operation carried out by `TextDocument::set_spans()`.
This caused overlapping spans for a cell with only a `=` symbol
(one for the actual token and one for the highlighting) to
miscalculate `start` and `end` value and a `length` value (of
`size_t` type) with a `0-1` substraction (result: 18446744073709551615)
causing `Utf32View::substring_view()` to fail the
`!Checked<size_t>::addition_would_overflow(offset, length)` assertion
This remove the possibility to directly alter `TextDocument`'s spans
thus forcing the utilization of `HighlighterClient::do_set_spans()`
interface function.
Proper refactor have been applied to
`CellSyntaxHighlighter::rehighlight()` function
Rather than creating a TextStyle struct, and then copying its fields
over to a TextAttributes, let's just create a TextAttributes to start
with. This also simplifies the syntax highlighting code by letting us
define underlines along with the other text styling.
This way we can get a compiler error about unhandled new language cases,
instead of a possible crash when running a program.
Also added a missing case to make it build now.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Even though the toolchain implicitly links against -lc, it does not know
where it should get LibC from except for the sysroot. In the case of
Clang this causes it to pick up the LibC stub instead, which might be
slightly outdated and feature missing symbols.
This is currently not an issue that manifests because we pass through
the dependency on LibC and other libraries by accident, which causes
CMake to link against the LibC target (instead of just the library),
and thus points the linker at the build output directory.
Since we are looking to fix that in the upcoming commits, let's make
sure that everything will still be able to find the proper LibC first.
TextDocument::set_spans() now also takes a "span collection index"
argument.
TextDocument keeps a map between a span collection index and its spans.
It merges the spans from all collections into a single set of spans
whenever set_spans() is called.
This allows us to style a document with multiple layers of spans, where
as previously we only supported a single layer of spans that was set
from the SyntaxHighlighter.
The SemanticSyntaxHighlighter uses TokenInfo results from the
language server to provide 'semantic' syntax highlighting, which
provides more fin-grained text spans results.
For example, the SemanticSyntaxHighlighter can color function calls,
member fields references and user-defined types in different colors.
With the simple lexer-only syntax highlighter, all of these tokens were
given the same text highlighting span type.
Since we have to provide immediate highlighting feedback to the user
after each edit and before we get the result for the language server,
we use a heuristic which computes the diff between the current tokens
and the last known tokens with compete semantic information
(We use LibDiff for this).
This heuristic is not very performant, and starts feeling sluggish with
bigger (~200 LOC) files.
A possible future improvement would be only computing the diff for
tokens in text ranges that have changes since the last commit.
This works at the Token level, which is quick and easy but has
drawbacks: We don't know when something is a property name or a value,
or if something is part of a selector. But, this works for now.
And use them to highlight javascript in HTML source.
This commit also changes how TextDocumentSpan::data is interpreted,
as it used to be an opaque pointer, but everyone stuffed an enum value
inside it, which made the values not unique to each highlighter;
that field is now a u64 serial id.
The syntax highlighters don't need to change their ways of stuffing
token types into that field, but a highlighter that calls another
nested highlighter needs to register the nested types for use with
token pairs.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
This is a little bit messy but the basic idea is:
Syntax::Highlighter now has a Syntax::HighlighterClient to talk to the
outside world. It mostly communicates in LibGUI primitives that are
available in headers, so inlineable.
GUI::TextEditor inherits from Syntax::HighlighterClient.
This let us to move GUI::JSSyntaxHighlighter to JS::SyntaxHighlighter
and remove LibGUI's dependency on LibJS.
