Only being able to complete enumerable properties is annoying,
especially since we updated everything to use the correct attributes.
Most standard built-in objects are *not* enumerable.
This commit fixes up the following:
- HMAC should not reuse a single hasher when successively updating
- AES Key should not assume its user key is valid signed char*
- Mode should have a virtual destructor
And adds a RFC5246 padding mode, which is required for TLS
There was a bug when dealing with a carry when the addition
result for the current word was UINT32_MAX.
This commit also adds a regression test for the bug.
You can now do:
touch a.txt b.txt c.txt d.txt
Also now you can't do:
touch --test # This created a "./--test" file
Also adds ArgsParser to the mix to better handle arguments :)
This commit introduces a way to get an object's own properties in the
correct order. The "correct order" for JS object properties is first all
array-like index properties (numeric keys) sorted by insertion order,
followed by all string properties sorted by insertion order.
Objects also now print correctly in the repl! Before this commit:
courage ~/js-tests $ js
> ({ foo: 1, bar: 2, baz: 3 })
{ bar: 2, foo: 1, baz: 3 }
After:
courage ~/js-tests $ js
> ({ foo: 1, bar: 2, baz: 3 })
{ foo: 1, bar: 2, baz: 3 }
It does not make much sense to receive an interrupt and process it
*much later*.
Also patches Userland/js to only create exceptions while some code is
actually running.
The kill system call accepts negative pids, as they
have special meaning:
pid == -1 means all processes the calling process has access to.
pid < -1 means every process who's process group ID is -pid.
I don't see any reason why the user space program should mask this.
JS::Value already has the empty state ({} or Value() gives you one.)
Use this instead of wrapping Value in Optional in some places.
I've also added Value::value_or(Value) so you can easily provide a
fallback value when one is not present.
This is required for template literals - we're not quite there yet, but at
least the parser can now tell us when this token is encountered -
currently this yields "Unexpected token Invalid". Not really helpful.
The character is a "backtick", but as we already have
TokenType::{StringLiteral,RegexLiteral} this seemed like a fitting name.
This also enables syntax highlighting for template literals in the js
REPL and LibGUI's JSSyntaxHighlighter.
These strings would be applied when inserted into the buffer, but are
not shown as part of the suggestion.
This commit also patches up Userland/js and Shell to use this
functionality
