The spec defines the only valid methods to be get, post, and dialog.
Post and dialog are currently unhandled and do nothing, any other value
(or no value specified) is defined by the spec to use the get method.
Now, you can optionally specify a ConsoleClient, to customise the
behaviour of the LibJS Console.
To customise the console, create a new ConsoleClient class that inherits
from JS::ConsoleClient and override all the abstract methods.
When Console::log() is called, if Console has a ConsoleClient,
ConsoleClient::log() is called instead.
These abstract methods are Value(void) functions: you can return a Value
which will be returned by the JavaScript function which calls that
method, in JavaScript.
Console methods are now Value(void) functions.
JavaScript functions in the JavaScript ConsoleObject are now implemented
as simple wrappers around Console methods.
This will make it possible for LibJS users to easily override the
default behaviour of JS console functions (even their return value!)
once we add a way to override Console behaviour.
Previously we would use the "content rect" as the viewport rect, which
could sometimes be smaller than the actual viewport rect as the content
size was based on the box geometry of the root layout node.
This fixes an issue on google.com where we would not render the main
logo image since it was "outside" the viewport. The root layout size
is currently very wrong on google.com but that's a separate issue. :^)
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'
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.
