You can now continue one list item across several lines, as long as you indent
it the same as the first line of the item. For example:
* This is the first item,
which spans multiple lines.
* This is the second item, which also has some
*emphasis* in it.
This now matches the output of
Program
(Variables)
...
(Children)
...
or
FunctionDeclaration 'foo'
(Parameters)
...
(Body)
...
etc.
Also don't print each consequent statement index, it doesn't add any
value.
Adds fully functioning template literals. Because template literals
contain expressions, most of the work has to be done in the Lexer rather
than the Parser. And because of the complexity of template literals
(expressions, nesting, escapes, etc), the Lexer needs to have some
template-related state.
When entering a new template literal, a TemplateLiteralStart token is
emitted. When inside a literal, all text will be parsed up until a '${'
or '`' (or EOF, but that's a syntax error) is seen, and then a
TemplateLiteralExprStart token is emitted. At this point, the Lexer
proceeds as normal, however it keeps track of the number of opening
and closing curly braces it has seen in order to determine the close
of the expression. Once it finds a matching curly brace for the '${',
a TemplateLiteralExprEnd token is emitted and the state is updated
accordingly.
When the Lexer is inside of a template literal, but not an expression,
and sees a '`', this must be the closing grave: a TemplateLiteralEnd
token is emitted.
The state required to correctly parse template strings consists of a
vector (for nesting) of two pieces of information: whether or not we
are in a template expression (as opposed to a template string); and
the count of the number of unmatched open curly braces we have seen
(only applicable if the Lexer is currently in a template expression).
TODO: Add support for template literal newlines in the JS REPL (this will
cause a syntax error currently):
> `foo
> bar`
'foo
bar'
This commit adds a CMakeLists.txt file that will be used by CLion to
configure the project and documentation explaining the steps to follow.
Configuring CLion this way enables important features like code
completion and file search. The configuration isn't perfect. There are
source files for which CLion cannot pick up the headers and asks to
manually include them from certain directories. But for the most part,
it works all right.
zeroPad => zero_pad
leftPad => left_pad
fieldWidth => field_width
These were the only variables with names in camelCase.
We were not consistent with the naming of these variables: some times we
called them zeroPad, leftPad, fieldWidth; other times we called them
zero_pad, left_pad, field_width.
These inconsistencies made the code hard to read, so I changed their
names to snake_case.
Also rename width => field_width in AK::print_hex()
These methods search from the beginning or end of a string for the
first character in the input StringView and returns the position in
the string of the first match. Note that this is not a substring match.
Each comes with single char overloads for efficiency.
We're starting with a very basic decoding API and only ISO-8859-1 and
UTF-8 decoding (and UTF-8 decoding is really a no-op since String is
expected to be UTF-8.)
We now look at the HTTP response headers for a Content-Type header and
try to parse it if present to find the text encoding.
If the text encoding is iso-8859-1, we turn all non-ASCII characters
into question marks. This makes Swedish Google load on my machine! :^)
We now store the response headers in a download object on the protocol
server side and pass it to the client when finishing up a download.
Response headers are passed as an IPC::Dictionary. :^)
Use Vector::resize_and_keep_capacity() to resize BigInt vectors to just
the right size without risking deallocation. Then do direct indexed
accesses to the underlying words (or use memset/memcpy.)
This gives a ~40% speed-up on the RSA tests in "test-crypto -t pk" :^)
Contrary to popular belief, not every implementation of TLS follows the
specs.
Some of them just drop the connection without sending a proper
close_notify, and we should handle that gracefully.
This change leads to between 10% and 35% performance improvement when executing
the RSA decryption method.
The main impact is to drastically reduce the number of allocations done in this
method from around 50% of the profile hits to less than 2%.
This changes the plus, minus, etc... operators from UnsignedBigInteger to use a
static helper method. The static methods do not allocate any variables, instead
all the required BigInteger output and temporary variables are required on call
as parameters.
This change already optimizes the number of allocations in complex operations
such as multiply or divide, by having a single allocation per call (instead of
one per loop).
This new API also provides a way to limit the number of allocations for complex
computations in other parts of the code. This is done by using these helpers in
any place that currently makes use of the standard operators.
We already skipped random semicolons in Parser::parse_program(), but now
they are properly matched and parsed as empty statements - and thus
recognized as a valid body of an if / else / while / ... statement.
The decrypted data is legally allowed to have any amount of padding, so
long as it is block-aligned, we should not assume that padding bytes
fall inside the same block, or that an entire block cannot be padding.
Fixes#2072
Adds the ability for function arguments to have default values. This
works for standard functions as well as arrow functions. Default values
are not printed in a <function>.toString() call, as nodes cannot print
their source string representation.
