beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-25 00:50:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 7
ladybird/Userland/Utilities/js.cpp

892 lines
34 KiB
C++
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
/*
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
LibJS: Port Value::to_object() to NonnullGCPtr
2023-04-13 13:26:41 +00:00
* Copyright (c) 2020-2023, Linus Groh <linusg@serenityos.org>
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
* Copyright (c) 2020-2022, Ali Mohammad Pur <mpfard@serenityos.org>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
*
Everything: Move to SPDX license identifiers in all files. 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 *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
*/
LibGUI+LibCore: Move GML property system from LibCore to LibGUI Since Core::Object properties are really only used by GML now that the Inspector is long gone, there's no need for these to pollute Core::Object. This patch adds a new GUI::Object class to hold properties, and makes it the new base class of GUI::Window, GUI::Widget and GUI::Layout. The "instantiate an object by name" mechanism that GML uses is also hoisted into GUI::Object as well.
2023-08-06 13:14:59 +00:00
#include <AK/JsonValue.h>
js: Take the script file as a command-line argument Now that we have the beginnings of a parser, let's take the script to run as a command-line argument and move all the test scripts into /home/anon/js :^) To run a script, simply use "js": $ js my-script.js To get an AST dump before execution, you can use "js -A"
2020-03-12 09:51:41 +00:00
#include <LibCore/ArgsParser.h>
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
#include <LibCore/ConfigFile.h>
js: Load and save history from/to ~/.js-history This is super useful when hacking on LibJS and in general :^)
2020-10-25 23:36:06 +00:00
#include <LibCore/StandardPaths.h>
LibCore+LibSystem: Move syscall wrappers from LibSystem to LibCore With this change, System::foo() becomes Core::System::foo(). Since LibCore builds on other systems than SerenityOS, we now have to make sure that wrappers work with just a standard C library underneath.
2021-11-23 09:59:50 +00:00
#include <LibCore/System.h>
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 02:19:58 +00:00
#include <LibJS/Bytecode/BasicBlock.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
#include <LibJS/Bytecode/Generator.h>
#include <LibJS/Bytecode/Interpreter.h>
js: Customise the behaviour of JS::Console with ReplConsoleClient This also makes our JavaScript tests not fail.
2020-05-04 14:09:05 +00:00
#include <LibJS/Console.h>
js: Add --use-test262-global option Add --use-test262-global option to expose the test262 global object instead of normal script object.
2023-06-06 08:23:34 +00:00
#include <LibJS/Contrib/Test262/GlobalObject.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
#include <LibJS/Interpreter.h>
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 18:27:43 +00:00
#include <LibJS/Parser.h>
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
#include <LibJS/Print.h>
LibJS: Move Console ownership from GlobalObject to ConsoleObject GlobalObject is now a regular object with no special properties :^)
2022-08-28 13:20:06 +00:00
#include <LibJS/Runtime/ConsoleObject.h>
js: Add a simple loadJSON(path) built-in to load JSON from a file This is very handy when you want to load data from /proc, for example.
2021-09-16 19:48:07 +00:00
#include <LibJS/Runtime/JSONObject.h>
js: Don't try to run empty scripts When you try to run script containing only whitespace, it will return undefined and doesn't do anything anyway. Let's match NodeJS behavior and just don't display anything. This only applies to REPL input and not to modules.
2022-03-07 17:11:13 +00:00
#include <LibJS/Runtime/StringPrototype.h>
LibJS+Userland: Port the JS Console object and direct callers to String
2023-02-10 16:40:52 +00:00
#include <LibJS/Runtime/ThrowableStringBuilder.h>
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
#include <LibJS/SourceTextModule.h>
LibLine: Rename LineEditor.{cpp,h} => Editor.{cpp,h}
2020-03-31 11:34:57 +00:00
#include <LibLine/Editor.h>
js: Port to LibMain :^) This wasn't particularly difficult, and there's not much use for the nicer interface yet either. While unveil() is of limited use in js(1) as it should be able to open arbitrary files, I feel like we should be able to add a pledge() call.
2021-11-22 19:25:30 +00:00
#include <LibMain/Main.h>
js: Convert non-UTF-8 encoded files to UTF-8 before parsing
2022-04-03 13:31:04 +00:00
#include <LibTextCodec/Decoder.h>
Userland: Install LibLine's signal handlers in the JS repl
2020-04-11 09:09:10 +00:00
#include <signal.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
RefPtr<JS::VM> g_vm;
js: Use `Core::Stream::File` in place of POSIX in `write_to_file()`
2023-02-04 03:15:47 +00:00
Vector<String> g_repl_statements;
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
JS::Handle<JS::Value> g_last_value = JS::make_handle(JS::js_undefined());
Userland/JS: Add the 'save("file")' repl command Calling save("file") in a repl saves all the typed lines so far into the specified file. It currently does not have great support for multilined functions since those get turned into one line.
2020-04-02 15:52:40 +00:00
LibJS: Rename GlobalObject::initialize() => initialize_global_object() This function was shadowing Object::initialize() which cannot be called on global objects and has a different set of parameters.
2021-03-17 15:52:26 +00:00
class ReplObject final : public JS::GlobalObject {
JS_OBJECT(ReplObject, JS::GlobalObject);
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
public:
LibJS: Let Shape store a Realm instead of a GlobalObject This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-08-01 18:27:20 +00:00
ReplObject(JS::Realm& realm)
: GlobalObject(realm)
{
}
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
virtual void initialize(JS::Realm&) override;
js: Use default constructor and destructor for global objects
2021-05-26 00:01:07 +00:00
virtual ~ReplObject() override = default;
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
private:
js: Convert JavaScript REPL to ThrowCompletionOr
2021-10-29 21:13:18 +00:00
JS_DECLARE_NATIVE_FUNCTION(exit_interpreter);
JS_DECLARE_NATIVE_FUNCTION(repl_help);
JS_DECLARE_NATIVE_FUNCTION(save_to_file);
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
JS_DECLARE_NATIVE_FUNCTION(load_ini);
js: Convert JavaScript REPL to ThrowCompletionOr
2021-10-29 21:13:18 +00:00
JS_DECLARE_NATIVE_FUNCTION(load_json);
LibJS: Fix that '_' no longer accessed the last value in the REPL This is now also not a concept that VM knows about and handled completely by the REPL.
2022-01-16 01:05:32 +00:00
JS_DECLARE_NATIVE_FUNCTION(last_value_getter);
js: Add a print() function to the environment It's really annoying to write `console.log(JSON.stringify(something))` in scripts, and the output is less than easily readable. This exposes the existing `print(Value)` function into the JS world, and allows us to write `print(something)` and get a neat representation in the console.
2022-02-14 08:34:50 +00:00
JS_DECLARE_NATIVE_FUNCTION(print);
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
};
js: Define load() in global object for scripts Having load() present is required in order to run test262.
2021-05-25 22:50:18 +00:00
class ScriptObject final : public JS::GlobalObject {
JS_OBJECT(ScriptObject, JS::GlobalObject);
public:
LibJS: Let Shape store a Realm instead of a GlobalObject This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-08-01 18:27:20 +00:00
ScriptObject(JS::Realm& realm)
: JS::GlobalObject(realm)
{
}
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
virtual void initialize(JS::Realm&) override;
js: Use default constructor and destructor for global objects
2021-05-26 00:01:07 +00:00
virtual ~ScriptObject() override = default;
js: Define load() in global object for scripts Having load() present is required in order to run test262.
2021-05-25 22:50:18 +00:00
private:
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
JS_DECLARE_NATIVE_FUNCTION(load_ini);
js: Convert JavaScript REPL to ThrowCompletionOr
2021-10-29 21:13:18 +00:00
JS_DECLARE_NATIVE_FUNCTION(load_json);
js: Add a print() function to the environment It's really annoying to write `console.log(JSON.stringify(something))` in scripts, and the output is less than easily readable. This exposes the existing `print(Value)` function into the JS world, and allows us to write `print(something)` and get a neat representation in the console.
2022-02-14 08:34:50 +00:00
JS_DECLARE_NATIVE_FUNCTION(print);
js: Define load() in global object for scripts Having load() present is required in order to run test262.
2021-05-25 22:50:18 +00:00
};
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
static bool s_dump_ast = false;
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 15:30:37 +00:00
static bool s_as_module = false;
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
static bool s_print_last_result = false;
js: Add command line flag for disabling ANSI colors
2021-11-23 20:46:28 +00:00
static bool s_strip_ansi = false;
js: Add command line flag for disabling source line hints
2021-11-23 21:02:19 +00:00
static bool s_disable_source_location_hints = false;
LibLine: Use Core::EventLoop for outer read loop This commit changes LibLine's internal structure to work in an event loop, and as a result, also switches it to being a Core::Object.
2020-05-26 10:34:39 +00:00
static RefPtr<Line::Editor> s_editor;
js: Convert `s_history_path` to String and propagate errors
2023-02-04 04:04:32 +00:00
static String s_history_path = String {};
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
static int s_repl_line_level = 0;
LibLine: Change get_line to return a Result<String, Error> This fixes a bunch of FIXME's in LibLine. Also handles the case where read() would read zero bytes in vt_dsr() and effectively block forever by erroring out. Fixes #2370
2020-05-25 12:27:07 +00:00
static bool s_fail_repl = false;
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
Everywhere: Remove the `AK::` qualifier from Stream usages
2023-02-10 00:00:18 +00:00
static ErrorOr<void> print(JS::Value value, Stream& stream)
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
{
JS::PrintContext print_context { .vm = *g_vm, .stream = stream, .strip_ansi = s_strip_ansi };
return JS::print(value, print_context);
}
enum class PrintTarget {
StandardError,
StandardOutput,
};
static ErrorOr<void> print(JS::Value value, PrintTarget target = PrintTarget::StandardOutput)
{
LibCore: Move Stream-based file into the `Core` namespace
2023-02-09 02:02:46 +00:00
auto stream = TRY(target == PrintTarget::StandardError ? Core::File::standard_error() : Core::File::standard_output());
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
return print(value, *stream);
}
js: Use String in `prompt_for_level()` and `read_next_piece()`
2023-02-04 03:08:42 +00:00
static ErrorOr<String> prompt_for_level(int level)
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
{
static StringBuilder prompt_builder;
prompt_builder.clear();
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
prompt_builder.append("> "sv);
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
for (auto i = 0; i < level; ++i)
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
prompt_builder.append(" "sv);
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
js: Use String in `prompt_for_level()` and `read_next_piece()`
2023-02-04 03:08:42 +00:00
return prompt_builder.to_string();
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
}
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
js: Use String in `prompt_for_level()` and `read_next_piece()`
2023-02-04 03:08:42 +00:00
static ErrorOr<String> read_next_piece()
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
{
StringBuilder piece;
Userland/js: Prompt for more input on labels and object keys Closes #2452
2020-05-30 17:12:11 +00:00
auto line_level_delta_for_next_line { 0 };
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
do {
js: Use String in `prompt_for_level()` and `read_next_piece()`
2023-02-04 03:08:42 +00:00
auto line_result = s_editor->get_line(TRY(prompt_for_level(s_repl_line_level)).to_deprecated_string());
LibLine: Change get_line to return a Result<String, Error> This fixes a bunch of FIXME's in LibLine. Also handles the case where read() would read zero bytes in vt_dsr() and effectively block forever by erroring out. Fixes #2370
2020-05-25 12:27:07 +00:00
Userland/js: Prompt for more input on labels and object keys Closes #2452
2020-05-30 17:12:11 +00:00
line_level_delta_for_next_line = 0;
LibLine: Change get_line to return a Result<String, Error> This fixes a bunch of FIXME's in LibLine. Also handles the case where read() would read zero bytes in vt_dsr() and effectively block forever by erroring out. Fixes #2370
2020-05-25 12:27:07 +00:00
if (line_result.is_error()) {
s_fail_repl = true;
js: Use String in `prompt_for_level()` and `read_next_piece()`
2023-02-04 03:08:42 +00:00
return String {};
LibLine: Change get_line to return a Result<String, Error> This fixes a bunch of FIXME's in LibLine. Also handles the case where read() would read zero bytes in vt_dsr() and effectively block forever by erroring out. Fixes #2370
2020-05-25 12:27:07 +00:00
}
auto& line = line_result.value();
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
s_editor->add_to_history(line);
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
piece.append(line);
js: Insert newline after each line in REPL mode This makes ASI work in the REPL.
2021-06-20 20:58:57 +00:00
piece.append('\n');
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
auto lexer = JS::Lexer(line);
Userland/js: Prompt for more input on labels and object keys Closes #2452
2020-05-30 17:12:11 +00:00
enum {
NotInLabelOrObjectKey,
InLabelOrObjectKeyIdentifier,
InLabelOrObjectKey
} label_state { NotInLabelOrObjectKey };
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
for (JS::Token token = lexer.next(); token.type() != JS::TokenType::Eof; token = lexer.next()) {
switch (token.type()) {
case JS::TokenType::BracketOpen:
case JS::TokenType::CurlyOpen:
case JS::TokenType::ParenOpen:
Userland/js: Prompt for more input on labels and object keys Closes #2452
2020-05-30 17:12:11 +00:00
label_state = NotInLabelOrObjectKey;
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
s_repl_line_level++;
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
break;
case JS::TokenType::BracketClose:
case JS::TokenType::CurlyClose:
case JS::TokenType::ParenClose:
Userland/js: Prompt for more input on labels and object keys Closes #2452
2020-05-30 17:12:11 +00:00
label_state = NotInLabelOrObjectKey;
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
s_repl_line_level--;
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
break;
Userland/js: Prompt for more input on labels and object keys Closes #2452
2020-05-30 17:12:11 +00:00
case JS::TokenType::Identifier:
case JS::TokenType::StringLiteral:
if (label_state == NotInLabelOrObjectKey)
label_state = InLabelOrObjectKeyIdentifier;
else
label_state = NotInLabelOrObjectKey;
break;
case JS::TokenType::Colon:
if (label_state == InLabelOrObjectKeyIdentifier)
label_state = InLabelOrObjectKey;
else
label_state = NotInLabelOrObjectKey;
break;
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
default:
break;
}
}
Userland/js: Prompt for more input on labels and object keys Closes #2452
2020-05-30 17:12:11 +00:00
if (label_state == InLabelOrObjectKey) {
// If there's a label or object literal key at the end of this line,
// prompt for more lines but do not change the line level.
line_level_delta_for_next_line += 1;
}
} while (s_repl_line_level + line_level_delta_for_next_line > 0);
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
js: Use String in `prompt_for_level()` and `read_next_piece()`
2023-02-04 03:08:42 +00:00
return piece.to_string();
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
}
js: Use `Core::Stream::File` in place of POSIX in `write_to_file()`
2023-02-04 03:15:47 +00:00
static ErrorOr<void> write_to_file(String const& path)
Userland/JS: Add the 'save("file")' repl command Calling save("file") in a repl saves all the typed lines so far into the specified file. It currently does not have great support for multilined functions since those get turned into one line.
2020-04-02 15:52:40 +00:00
{
LibCore: Move Stream-based file into the `Core` namespace
2023-02-09 02:02:46 +00:00
auto file = TRY(Core::File::open(path, Core::File::OpenMode::Write, 0666));
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
for (size_t i = 0; i < g_repl_statements.size(); i++) {
js: Use `Core::Stream::File` in place of POSIX in `write_to_file()`
2023-02-04 03:15:47 +00:00
auto line = g_repl_statements[i].bytes();
if (line.size() > 0 && i != g_repl_statements.size() - 1) {
Everywhere: Remove unintentional partial stream reads and writes
2023-03-01 16:24:50 +00:00
TRY(file->write_until_depleted(line));
Userland/JS: Add the 'save("file")' repl command Calling save("file") in a repl saves all the typed lines so far into the specified file. It currently does not have great support for multilined functions since those get turned into one line.
2020-04-02 15:52:40 +00:00
}
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
if (i != g_repl_statements.size() - 1) {
js: Use `Core::Stream::File` in place of POSIX in `write_to_file()`
2023-02-04 03:15:47 +00:00
TRY(file->write_value('\n'));
Userland/JS: Add the 'save("file")' repl command Calling save("file") in a repl saves all the typed lines so far into the specified file. It currently does not have great support for multilined functions since those get turned into one line.
2020-04-02 15:52:40 +00:00
}
}
js: Use `Core::Stream::File` in place of POSIX in `write_to_file()`
2023-02-04 03:15:47 +00:00
file->close();
return {};
Userland/JS: Add the 'save("file")' repl command Calling save("file") in a repl saves all the typed lines so far into the specified file. It currently does not have great support for multilined functions since those get turned into one line.
2020-04-02 15:52:40 +00:00
}
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
static ErrorOr<bool> parse_and_run(JS::Interpreter& interpreter, StringView source, StringView source_name)
js: Throw a regular SyntaxError for errors from the parser
2020-05-14 15:29:24 +00:00
{
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
enum class ReturnEarly {
No,
Yes,
};
js: Throw a regular SyntaxError for errors from the parser
2020-05-14 15:29:24 +00:00
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
JS::ThrowCompletionOr<JS::Value> result { JS::js_undefined() };
js: Throw a regular SyntaxError for errors from the parser
2020-05-14 15:29:24 +00:00
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
auto run_script_or_module = [&](auto& script_or_module) -> ErrorOr<ReturnEarly> {
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
if (s_dump_ast)
js: Use generic reference instead of Variant<A,B> As the two types are used in exactly the same way, just make the lambda generic over the type instead of explicitly moving them into a variant and then visiting with a generic lambda.
2022-01-24 09:13:05 +00:00
script_or_module->parse_node().dump(0);
LibJS: Convert Interpreter::run() to ThrowCompletionOr<Value> Instead of making it a void function, checking for an exception, and then receiving the relevant result via VM::last_value(), we can consolidate all of this by using completions. This allows us to remove more uses of VM::exception(), and all uses of VM::last_value().
2022-01-08 20:28:27 +00:00
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 13:59:18 +00:00
if (auto* bytecode_interpreter = g_vm->bytecode_interpreter_if_exists()) {
result = bytecode_interpreter->run(*script_or_module);
LibJS: Don't generate bytecode after we've encountered a parser error
2021-06-10 19:04:12 +00:00
} else {
js: Use generic reference instead of Variant<A,B> As the two types are used in exactly the same way, just make the lambda generic over the type instead of explicitly moving them into a variant and then visiting with a generic lambda.
2022-01-24 09:13:05 +00:00
result = interpreter.run(*script_or_module);
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
}
return ReturnEarly::No;
};
if (!s_as_module) {
auto script_or_error = JS::Script::parse(source, interpreter.realm(), source_name);
if (script_or_error.is_error()) {
auto error = script_or_error.error()[0];
auto hint = error.source_location_hint(source);
if (!hint.is_empty())
outln("{}", hint);
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
auto error_string = TRY(error.to_string());
outln("{}", error_string);
result = interpreter.vm().throw_completion<JS::SyntaxError>(move(error_string));
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
} else {
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
auto return_early = TRY(run_script_or_module(script_or_error.value()));
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
if (return_early == ReturnEarly::Yes)
return true;
}
} else {
auto module_or_error = JS::SourceTextModule::parse(source, interpreter.realm(), source_name);
if (module_or_error.is_error()) {
auto error = module_or_error.error()[0];
auto hint = error.source_location_hint(source);
if (!hint.is_empty())
outln("{}", hint);
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
auto error_string = TRY(error.to_string());
outln("{}", error_string);
result = interpreter.vm().throw_completion<JS::SyntaxError>(move(error_string));
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
} else {
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
auto return_early = TRY(run_script_or_module(module_or_error.value()));
LibJS: Refactor interpreter to use Script and Source Text Modules This also refactors interpreter creation to follow InitializeHostDefinedRealm, but I couldn't fit it in the title :^) This allows us to follow the spec much more closely rather than being completely ad-hoc with just the parse node instead of having all the surrounding data such as the realm of the parse node. The interpreter creation refactor creates the global execution context once and doesn't take it off the stack. This allows LibWeb to take the global execution context and manually handle it, following the HTML spec. The HTML spec calls this the "realm execution context" of the environment settings object. It also allows us to specify the globalThis type, as it can be different from the global object type. For example, on the web, Window global objects use a WindowProxy global this value to enforce the same origin policy on operations like [[GetOwnProperty]]. Finally, it allows us to directly call Program::execute in perform_eval and perform_shadow_realm_eval as this moves global_declaration_instantiation into Interpreter::run (ScriptEvaluation) as per the spec. Note that this doesn't evalulate Source Text Modules yet or refactor the bytecode interpreter, that's work for future us :^) This patch was originally build by Luke for the environment settings object change but was also needed for modules. So I (davidot) have modified it with the new completion changes and setup for that. Co-authored-by: davidot <davidot@serenityos.org>
2022-01-16 12:16:04 +00:00
if (return_early == ReturnEarly::Yes)
return true;
LibJS: Don't generate bytecode after we've encountered a parser error
2021-06-10 19:04:12 +00:00
}
js: Throw a regular SyntaxError for errors from the parser
2020-05-14 15:29:24 +00:00
}
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
auto handle_exception = [&](JS::Value thrown_value) -> ErrorOr<void> {
warnln("Uncaught exception: ");
TRY(print(thrown_value, PrintTarget::StandardError));
warnln();
LibJS+Everywhere: Remove VM::exception() and most related functions This commit removes all exception related code: Remove VM::exception(), VM::throw_exception() etc. Any leftover throw_exception calls are moved to throw_completion. The one method left is clear_exception() which is now a no-op. Most of these calls are just to clear whatever exception might have been thrown when handling a Completion. So to have a cleaner commit this will be removed in a next commit. It also removes the actual Exception and TemporaryClearException classes since these are no longer used. In any spot where the exception was actually used an attempt was made to preserve that behavior. However since it is no longer tracked by the VM we cannot access exceptions which were thrown in previous calls. There are two such cases which might have different behavior: - In Web::DOM::Document::interpreter() the on_call_stack_emptied hook used to print any uncaught exception but this is now no longer possible as the VM does not store uncaught exceptions. - In js the code used to be interruptable by throwing an exception on the VM. This is no longer possible but was already somewhat fragile before as you could happen to throw an exception just before a VERIFY.
2022-02-07 14:12:41 +00:00
if (!thrown_value.is_object() || !is<JS::Error>(thrown_value.as_object()))
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
return {};
js: Use const where possible in `parse_and_run()`
2023-02-04 04:09:35 +00:00
auto const& traceback = static_cast<JS::Error const&>(thrown_value.as_object()).traceback();
LibJS: Consolidate exception function names and source ranges Instead of storing the function names (in a badly named Vector<String>) and source ranges separately, consolidate them into a new struct: TracebackFrame. This makes it both easier to use now and easier to extend in the future. Unlike before we now keep each call frame's current node source range in the traceback frame next to the function name, meaning we can display line and column numbers outside of the VM and after the call stack is emptied.
2021-04-24 16:15:02 +00:00
if (traceback.size() > 1) {
js: Limit number of consecutive error trace entries being printed > function f(){f()}f() Uncaught exception: [RuntimeError]: Call stack size limit exceeded -> f 1234 more calls -> (global execution context) > function a(x){if(x>0){a(x-1)}else{throw Error()}}function b(x){if(x>0){b(x-1)}else{a(5)}}function c(){b(2)}c() Uncaught exception: [Error] -> a 5 more calls -> b -> b -> b -> c -> (global execution context)
2020-11-08 12:58:49 +00:00
unsigned repetitions = 0;
LibJS: Consolidate exception function names and source ranges Instead of storing the function names (in a badly named Vector<String>) and source ranges separately, consolidate them into a new struct: TracebackFrame. This makes it both easier to use now and easier to extend in the future. Unlike before we now keep each call frame's current node source range in the traceback frame next to the function name, meaning we can display line and column numbers outside of the VM and after the call stack is emptied.
2021-04-24 16:15:02 +00:00
for (size_t i = 0; i < traceback.size(); ++i) {
js: Use const where possible in `parse_and_run()`
2023-02-04 04:09:35 +00:00
auto const& traceback_frame = traceback[i];
LibJS: Consolidate exception function names and source ranges Instead of storing the function names (in a badly named Vector<String>) and source ranges separately, consolidate them into a new struct: TracebackFrame. This makes it both easier to use now and easier to extend in the future. Unlike before we now keep each call frame's current node source range in the traceback frame next to the function name, meaning we can display line and column numbers outside of the VM and after the call stack is emptied.
2021-04-24 16:15:02 +00:00
if (i + 1 < traceback.size()) {
js: Use const where possible in `parse_and_run()`
2023-02-04 04:09:35 +00:00
auto const& next_traceback_frame = traceback[i + 1];
LibJS: Consolidate exception function names and source ranges Instead of storing the function names (in a badly named Vector<String>) and source ranges separately, consolidate them into a new struct: TracebackFrame. This makes it both easier to use now and easier to extend in the future. Unlike before we now keep each call frame's current node source range in the traceback frame next to the function name, meaning we can display line and column numbers outside of the VM and after the call stack is emptied.
2021-04-24 16:15:02 +00:00
if (next_traceback_frame.function_name == traceback_frame.function_name) {
repetitions++;
continue;
}
js: Limit number of consecutive error trace entries being printed > function f(){f()}f() Uncaught exception: [RuntimeError]: Call stack size limit exceeded -> f 1234 more calls -> (global execution context) > function a(x){if(x>0){a(x-1)}else{throw Error()}}function b(x){if(x>0){b(x-1)}else{a(5)}}function c(){b(2)}c() Uncaught exception: [Error] -> a 5 more calls -> b -> b -> b -> c -> (global execution context)
2020-11-08 12:58:49 +00:00
}
if (repetitions > 4) {
// If more than 5 (1 + >4) consecutive function calls with the same name, print
// the name only once and show the number of repetitions instead. This prevents
// printing ridiculously large call stacks of recursive functions.
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
warnln(" -> {}", traceback_frame.function_name);
warnln(" {} more calls", repetitions);
js: Limit number of consecutive error trace entries being printed > function f(){f()}f() Uncaught exception: [RuntimeError]: Call stack size limit exceeded -> f 1234 more calls -> (global execution context) > function a(x){if(x>0){a(x-1)}else{throw Error()}}function b(x){if(x>0){b(x-1)}else{a(5)}}function c(){b(2)}c() Uncaught exception: [Error] -> a 5 more calls -> b -> b -> b -> c -> (global execution context)
2020-11-08 12:58:49 +00:00
} else {
for (size_t j = 0; j < repetitions + 1; ++j)
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
warnln(" -> {}", traceback_frame.function_name);
js: Limit number of consecutive error trace entries being printed > function f(){f()}f() Uncaught exception: [RuntimeError]: Call stack size limit exceeded -> f 1234 more calls -> (global execution context) > function a(x){if(x>0){a(x-1)}else{throw Error()}}function b(x){if(x>0){b(x-1)}else{a(5)}}function c(){b(2)}c() Uncaught exception: [Error] -> a 5 more calls -> b -> b -> b -> c -> (global execution context)
2020-11-08 12:58:49 +00:00
}
repetitions = 0;
}
js: Print call stack on exception thrown outside the global context
2020-06-02 13:12:04 +00:00
}
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
return {};
js: Handle exceptions thrown during value printing If an exception was thrown while printing the last computed value in the REPL, it would always assert on next input. Something like this would always assert: > a=[];Object.defineProperty(a,"0",{get:()=>{throw ""}}) > 1 + 2
2021-01-29 08:16:06 +00:00
};
LibJS: Fix that '_' no longer accessed the last value in the REPL This is now also not a concept that VM knows about and handled completely by the REPL.
2022-01-16 01:05:32 +00:00
if (!result.is_error())
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
g_last_value = JS::make_handle(result.value());
LibJS: Fix that '_' no longer accessed the last value in the REPL This is now also not a concept that VM knows about and handled completely by the REPL.
2022-01-16 01:05:32 +00:00
LibJS: Convert Interpreter::run() to ThrowCompletionOr<Value> Instead of making it a void function, checking for an exception, and then receiving the relevant result via VM::last_value(), we can consolidate all of this by using completions. This allows us to remove more uses of VM::exception(), and all uses of VM::last_value().
2022-01-08 20:28:27 +00:00
if (result.is_error()) {
LibJS+Everywhere: Remove VM::exception() and most related functions This commit removes all exception related code: Remove VM::exception(), VM::throw_exception() etc. Any leftover throw_exception calls are moved to throw_completion. The one method left is clear_exception() which is now a no-op. Most of these calls are just to clear whatever exception might have been thrown when handling a Completion. So to have a cleaner commit this will be removed in a next commit. It also removes the actual Exception and TemporaryClearException classes since these are no longer used. In any spot where the exception was actually used an attempt was made to preserve that behavior. However since it is no longer tracked by the VM we cannot access exceptions which were thrown in previous calls. There are two such cases which might have different behavior: - In Web::DOM::Document::interpreter() the on_call_stack_emptied hook used to print any uncaught exception but this is now no longer possible as the VM does not store uncaught exceptions. - In js the code used to be interruptable by throwing an exception on the VM. This is no longer possible but was already somewhat fragile before as you could happen to throw an exception just before a VERIFY.
2022-02-07 14:12:41 +00:00
VERIFY(result.throw_completion().value().has_value());
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
TRY(handle_exception(*result.release_error().value()));
LibJS: Make Errors fully spec compliant The previous handling of the name and message properties specifically was breaking websites that created their own error types and relied on the error prototype working correctly - not assuming an JS::Error this object, that is. The way it works now, and it is supposed to work, is: - Error.prototype.name and Error.prototype.message just have initial string values and are no longer getters/setters - When constructing an error with a message, we create a regular property on the newly created object, so a lookup of the message property will either get it from the object directly or go though the prototype chain - Internal m_name/m_message properties are no longer needed and removed This makes printing errors slightly more complicated, as we can no longer rely on the (safe) internal properties, and cannot trust a property lookup either - get_without_side_effects() is used to solve this, it's not perfect but something we can revisit later. I did some refactoring along the way, there was some really old stuff in there - accessing vm.call_frame().arguments[0] is not something we (have to) do anymore :^) Fixes #6245.
2021-04-11 22:08:28 +00:00
return false;
js: Handle exceptions thrown during value printing If an exception was thrown while printing the last computed value in the REPL, it would always assert on next input. Something like this would always assert: > a=[];Object.defineProperty(a,"0",{get:()=>{throw ""}}) > 1 + 2
2021-01-29 08:16:06 +00:00
}
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
if (s_print_last_result) {
TRY(print(result.value()));
warnln();
}
js: Throw a regular SyntaxError for errors from the parser
2020-05-14 15:29:24 +00:00
return true;
}
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 18:24:32 +00:00
static JS::ThrowCompletionOr<JS::Value> load_ini_impl(JS::VM& vm)
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
{
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 18:24:32 +00:00
auto& realm = *vm.current_realm();
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-15 23:20:49 +00:00
LibJS+Everywhere: Rename Value::to_string to to_deprecated_string
2023-01-13 15:29:02 +00:00
auto filename = TRY(vm.argument(0).to_deprecated_string(vm));
LibCore: Move Stream-based file into the `Core` namespace
2023-02-09 02:02:46 +00:00
auto file_or_error = Core::File::open(filename, Core::File::OpenMode::Read);
js: Port to Core::Stream
2022-09-14 14:19:11 +00:00
if (file_or_error.is_error())
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
return vm.throw_completion<JS::Error>(TRY_OR_THROW_OOM(vm, String::formatted("Failed to open '{}': {}", filename, file_or_error.error())));
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
js: Port to Core::Stream
2022-09-14 14:19:11 +00:00
auto config_file = MUST(Core::ConfigFile::open(filename, file_or_error.release_value()));
LibJS: Convert Object::create() to NonnullGCPtr
2022-12-13 20:49:50 +00:00
auto object = JS::Object::create(realm, realm.intrinsics().object_prototype());
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
for (auto const& group : config_file->groups()) {
LibJS: Convert Object::create() to NonnullGCPtr
2022-12-13 20:49:50 +00:00
auto group_object = JS::Object::create(realm, realm.intrinsics().object_prototype());
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
for (auto const& key : config_file->keys(group)) {
auto entry = config_file->read_entry(group, key);
LibJS: Replace standalone js_string() with PrimitiveString::create() Note that js_rope_string() has been folded into this, the old name was misleading - it would not always create a rope string, only if both sides are not empty strings. Use a three-argument create() overload instead.
2022-12-06 22:17:27 +00:00
group_object->define_direct_property(key, JS::PrimitiveString::create(vm, move(entry)), JS::Attribute::Enumerable | JS::Attribute::Configurable | JS::Attribute::Writable);
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
}
object->define_direct_property(group, group_object, JS::Attribute::Enumerable | JS::Attribute::Configurable | JS::Attribute::Writable);
}
return object;
}
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 18:24:32 +00:00
static JS::ThrowCompletionOr<JS::Value> load_json_impl(JS::VM& vm)
js: Add a simple loadJSON(path) built-in to load JSON from a file This is very handy when you want to load data from /proc, for example.
2021-09-16 19:48:07 +00:00
{
js: Remove DeprecatedString usage in `load_json_impl()`
2023-02-04 14:17:06 +00:00
auto filename = TRY(vm.argument(0).to_string(vm));
LibCore: Move Stream-based file into the `Core` namespace
2023-02-09 02:02:46 +00:00
auto file_or_error = Core::File::open(filename, Core::File::OpenMode::Read);
js: Port to Core::Stream
2022-09-14 14:19:11 +00:00
if (file_or_error.is_error())
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
return vm.throw_completion<JS::Error>(TRY_OR_THROW_OOM(vm, String::formatted("Failed to open '{}': {}", filename, file_or_error.error())));
js: Port to Core::Stream
2022-09-14 14:19:11 +00:00
LibCore: Rename `Stream::read_all` to `read_until_eof` This generally seems like a better name, especially if we somehow also need a better name for "read the entire buffer, but not the entire file" somewhere down the line.
2022-12-11 16:49:00 +00:00
auto file_contents_or_error = file_or_error.value()->read_until_eof();
js: Port to Core::Stream
2022-09-14 14:19:11 +00:00
if (file_contents_or_error.is_error())
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
return vm.throw_completion<JS::Error>(TRY_OR_THROW_OOM(vm, String::formatted("Failed to read '{}': {}", filename, file_contents_or_error.error())));
js: Port to Core::Stream
2022-09-14 14:19:11 +00:00
auto json = JsonValue::from_string(file_contents_or_error.value());
AK: Make JSON parser return ErrorOr<JsonValue> (instead of Optional) Also add slightly richer parse errors now that we can include a string literal with returned errors. This will allow us to use TRY() when working with JSON data.
2021-11-15 00:46:51 +00:00
if (json.is_error())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 19:33:17 +00:00
return vm.throw_completion<JS::SyntaxError>(JS::ErrorType::JsonMalformed);
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 18:24:32 +00:00
return JS::JSONObject::parse_json_value(vm, json.value());
js: Add a simple loadJSON(path) built-in to load JSON from a file This is very handy when you want to load data from /proc, for example.
2021-09-16 19:48:07 +00:00
}
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
void ReplObject::initialize(JS::Realm& realm)
LibJS: Move builtin prototypes to the global object This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18 11:18:06 +00:00
{
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
Base::initialize(realm);
LibJS: Turn initialize_global_object() into a regular initialize() There's nothing special about global object initialization anymore, this can just work the same way as for any other object now.
2022-08-28 13:42:50 +00:00
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-05 23:15:08 +00:00
define_direct_property("global", this, JS::Attribute::Enumerable);
LibJS: Remove the default length & attributes from define_native_* These are usually incorrect, and people sometimes forget to add the correct values as a result of them being optional, so they should just be specified explicitly.
2021-07-05 22:12:54 +00:00
u8 attr = JS::Attribute::Configurable | JS::Attribute::Writable | JS::Attribute::Enumerable;
LibJS: Pass Realm to define_native_{accessor,function}() This is needed so that the allocated NativeFunction receives the correct realm, usually forwarded from the Object's initialize() function, rather than using the current realm.
2022-08-22 20:47:35 +00:00
define_native_function(realm, "exit", exit_interpreter, 0, attr);
define_native_function(realm, "help", repl_help, 0, attr);
define_native_function(realm, "save", save_to_file, 1, attr);
define_native_function(realm, "loadINI", load_ini, 1, attr);
define_native_function(realm, "loadJSON", load_json, 1, attr);
define_native_function(realm, "print", print, 1, attr);
LibJS: Fix that '_' no longer accessed the last value in the REPL This is now also not a concept that VM knows about and handled completely by the REPL.
2022-01-16 01:05:32 +00:00
define_native_accessor(
LibJS: Pass Realm to define_native_{accessor,function}() This is needed so that the allocated NativeFunction receives the correct realm, usually forwarded from the Object's initialize() function, rather than using the current realm.
2022-08-22 20:47:35 +00:00
realm,
LibJS: Fix that '_' no longer accessed the last value in the REPL This is now also not a concept that VM knows about and handled completely by the REPL.
2022-01-16 01:05:32 +00:00
"_",
LibJS: Remove GlobalObject parameter from native functions
2022-08-22 10:48:08 +00:00
[](JS::VM&) {
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
return g_last_value.value();
LibJS: Fix that '_' no longer accessed the last value in the REPL This is now also not a concept that VM knows about and handled completely by the REPL.
2022-01-16 01:05:32 +00:00
},
LibJS: Remove GlobalObject parameter from native functions
2022-08-22 10:48:08 +00:00
[](JS::VM& vm) -> JS::ThrowCompletionOr<JS::Value> {
auto& global_object = vm.get_global_object();
LibJS: Fix that '_' no longer accessed the last value in the REPL This is now also not a concept that VM knows about and handled completely by the REPL.
2022-01-16 01:05:32 +00:00
VERIFY(is<ReplObject>(global_object));
outln("Disable writing last value to '_'");
// We must delete first otherwise this setter gets called recursively.
TRY(global_object.internal_delete(JS::PropertyKey { "_" }));
auto value = vm.argument(0);
TRY(global_object.internal_set(JS::PropertyKey { "_" }, value, &global_object));
return value;
},
attr);
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
}
js: Convert JavaScript REPL to ThrowCompletionOr
2021-10-29 21:13:18 +00:00
JS_DEFINE_NATIVE_FUNCTION(ReplObject::save_to_file)
Userland/JS: Add the 'save("file")' repl command Calling save("file") in a repl saves all the typed lines so far into the specified file. It currently does not have great support for multilined functions since those get turned into one line.
2020-04-02 15:52:40 +00:00
{
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 16:36:49 +00:00
if (!vm.argument_count())
Userland/JS: Add the 'save("file")' repl command Calling save("file") in a repl saves all the typed lines so far into the specified file. It currently does not have great support for multilined functions since those get turned into one line.
2020-04-02 15:52:40 +00:00
return JS::Value(false);
js: Use `Core::Stream::File` in place of POSIX in `write_to_file()`
2023-02-04 03:15:47 +00:00
auto const save_path = TRY(vm.argument(0).to_string(vm));
if (!write_to_file(save_path).is_error()) {
Userland/JS: Add the 'save("file")' repl command Calling save("file") in a repl saves all the typed lines so far into the specified file. It currently does not have great support for multilined functions since those get turned into one line.
2020-04-02 15:52:40 +00:00
return JS::Value(true);
}
return JS::Value(false);
}
js: Add assertNotReached() function in test mode
2020-04-13 13:04:24 +00:00
js: Convert JavaScript REPL to ThrowCompletionOr
2021-10-29 21:13:18 +00:00
JS_DEFINE_NATIVE_FUNCTION(ReplObject::exit_interpreter)
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
{
js: Save REPL history when exiting interpreter with `exit()` Previously, we only saved the REPL history when the interpreter was shutdown with a signal. This change ensures that we save the history when a user uses `exit()`.
2023-02-10 16:02:52 +00:00
s_editor->save_history(s_history_path.to_deprecated_string());
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 16:36:49 +00:00
if (!vm.argument_count())
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
exit(0);
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 13:00:56 +00:00
exit(TRY(vm.argument(0).to_number(vm)).as_double());
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
}
js: Add assertNotReached() function in test mode
2020-04-13 13:04:24 +00:00
js: Convert JavaScript REPL to ThrowCompletionOr
2021-10-29 21:13:18 +00:00
JS_DEFINE_NATIVE_FUNCTION(ReplObject::repl_help)
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
{
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
warnln("REPL commands:");
warnln(" exit(code): exit the REPL with specified code. Defaults to 0.");
warnln(" help(): display this menu");
warnln(" loadINI(file): load the given file as INI.");
warnln(" loadJSON(file): load the given file as JSON.");
warnln(" print(value): pretty-print the given JS value.");
warnln(" save(file): write REPL input history to the given file. For example: save(\"foo.txt\")");
js: Output text using printf() and return undefined in help()
2020-04-13 20:08:54 +00:00
return JS::js_undefined();
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
}
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
JS_DEFINE_NATIVE_FUNCTION(ReplObject::load_ini)
{
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 18:24:32 +00:00
return load_ini_impl(vm);
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
}
js: Convert JavaScript REPL to ThrowCompletionOr
2021-10-29 21:13:18 +00:00
JS_DEFINE_NATIVE_FUNCTION(ReplObject::load_json)
js: Add a simple loadJSON(path) built-in to load JSON from a file This is very handy when you want to load data from /proc, for example.
2021-09-16 19:48:07 +00:00
{
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 18:24:32 +00:00
return load_json_impl(vm);
js: Add a simple loadJSON(path) built-in to load JSON from a file This is very handy when you want to load data from /proc, for example.
2021-09-16 19:48:07 +00:00
}
js: Add a print() function to the environment It's really annoying to write `console.log(JSON.stringify(something))` in scripts, and the output is less than easily readable. This exposes the existing `print(Value)` function into the JS world, and allows us to write `print(something)` and get a neat representation in the console.
2022-02-14 08:34:50 +00:00
JS_DEFINE_NATIVE_FUNCTION(ReplObject::print)
{
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
auto result = ::print(vm.argument(0));
if (result.is_error())
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
return g_vm->throw_completion<JS::InternalError>(TRY_OR_THROW_OOM(*g_vm, String::formatted("Failed to print value: {}", result.error())));
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
outln();
js: Add a print() function to the environment It's really annoying to write `console.log(JSON.stringify(something))` in scripts, and the output is less than easily readable. This exposes the existing `print(Value)` function into the JS world, and allows us to write `print(something)` and get a neat representation in the console.
2022-02-14 08:34:50 +00:00
return JS::js_undefined();
}
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
void ScriptObject::initialize(JS::Realm& realm)
js: Define load() in global object for scripts Having load() present is required in order to run test262.
2021-05-25 22:50:18 +00:00
{
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 06:41:28 +00:00
Base::initialize(realm);
LibJS: Turn initialize_global_object() into a regular initialize() There's nothing special about global object initialization anymore, this can just work the same way as for any other object now.
2022-08-28 13:42:50 +00:00
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-05 23:15:08 +00:00
define_direct_property("global", this, JS::Attribute::Enumerable);
LibJS: Remove the default length & attributes from define_native_* These are usually incorrect, and people sometimes forget to add the correct values as a result of them being optional, so they should just be specified explicitly.
2021-07-05 22:12:54 +00:00
u8 attr = JS::Attribute::Configurable | JS::Attribute::Writable | JS::Attribute::Enumerable;
LibJS: Pass Realm to define_native_{accessor,function}() This is needed so that the allocated NativeFunction receives the correct realm, usually forwarded from the Object's initialize() function, rather than using the current realm.
2022-08-22 20:47:35 +00:00
define_native_function(realm, "loadINI", load_ini, 1, attr);
define_native_function(realm, "loadJSON", load_json, 1, attr);
define_native_function(realm, "print", print, 1, attr);
js: Define load() in global object for scripts Having load() present is required in order to run test262.
2021-05-25 22:50:18 +00:00
}
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
JS_DEFINE_NATIVE_FUNCTION(ScriptObject::load_ini)
{
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 18:24:32 +00:00
return load_ini_impl(vm);
js: Add a loadINI() function for loading INI files :^) This works the same way as loadJSON, except it loads INI files and always returns an object.
2022-06-06 17:51:02 +00:00
}
js: Convert JavaScript REPL to ThrowCompletionOr
2021-10-29 21:13:18 +00:00
JS_DEFINE_NATIVE_FUNCTION(ScriptObject::load_json)
js: Add a simple loadJSON(path) built-in to load JSON from a file This is very handy when you want to load data from /proc, for example.
2021-09-16 19:48:07 +00:00
{
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 18:24:32 +00:00
return load_json_impl(vm);
js: Add a simple loadJSON(path) built-in to load JSON from a file This is very handy when you want to load data from /proc, for example.
2021-09-16 19:48:07 +00:00
}
js: Add a print() function to the environment It's really annoying to write `console.log(JSON.stringify(something))` in scripts, and the output is less than easily readable. This exposes the existing `print(Value)` function into the JS world, and allows us to write `print(something)` and get a neat representation in the console.
2022-02-14 08:34:50 +00:00
JS_DEFINE_NATIVE_FUNCTION(ScriptObject::print)
{
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
auto result = ::print(vm.argument(0));
if (result.is_error())
LibJS+Everywhere: Convert JS::Error to String This includes an Error::create overload to create an Error from a UTF-8 StringView. If creating a String from that view fails, the factory will return an OOM InternalError instead. VM::throw_completion can also make use of this overload via its perfect forwarding.
2023-02-16 19:09:11 +00:00
return g_vm->throw_completion<JS::InternalError>(TRY_OR_THROW_OOM(*g_vm, String::formatted("Failed to print value: {}", result.error())));
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
outln();
js: Add a print() function to the environment It's really annoying to write `console.log(JSON.stringify(something))` in scripts, and the output is less than easily readable. This exposes the existing `print(Value)` function into the JS world, and allows us to write `print(something)` and get a neat representation in the console.
2022-02-14 08:34:50 +00:00
return JS::js_undefined();
}
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
static ErrorOr<void> repl(JS::Interpreter& interpreter)
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
{
LibLine: Change get_line to return a Result<String, Error> This fixes a bunch of FIXME's in LibLine. Also handles the case where read() would read zero bytes in vt_dsr() and effectively block forever by erroring out. Fixes #2370
2020-05-25 12:27:07 +00:00
while (!s_fail_repl) {
js: Use String in `prompt_for_level()` and `read_next_piece()`
2023-02-04 03:08:42 +00:00
auto const piece = TRY(read_next_piece());
js: Don't try to run empty scripts When you try to run script containing only whitespace, it will return undefined and doesn't do anything anyway. Let's match NodeJS behavior and just don't display anything. This only applies to REPL input and not to modules.
2022-03-07 17:11:13 +00:00
if (Utf8View { piece }.trim(JS::whitespace_characters).is_empty())
js: Don't exit the REPL when pressing enter on an empty line
2020-03-31 11:29:42 +00:00
continue;
js: Don't try to run empty scripts When you try to run script containing only whitespace, it will return undefined and doesn't do anything anyway. Let's match NodeJS behavior and just don't display anything. This only applies to REPL input and not to modules.
2022-03-07 17:11:13 +00:00
js: Use `Core::Stream::File` in place of POSIX in `write_to_file()`
2023-02-04 03:15:47 +00:00
g_repl_statements.append(piece);
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
TRY(parse_and_run(interpreter, piece, "REPL"sv));
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
}
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
return {};
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
}
js: Make it a little easier to add new AST builder functions
2020-03-09 20:58:27 +00:00
js: Interrupt running script or REPL evaluation when receiving SIGINT
2020-04-24 16:59:16 +00:00
static Function<void()> interrupt_interpreter;
Userland: Mark compilation-unit-only functions as static This enables a nice warning in case a function becomes dead code.
2020-08-10 21:48:37 +00:00
static void sigint_handler()
js: Interrupt running script or REPL evaluation when receiving SIGINT
2020-04-24 16:59:16 +00:00
{
interrupt_interpreter();
}
js: Customise the behaviour of JS::Console with ReplConsoleClient This also makes our JavaScript tests not fail.
2020-05-04 14:09:05 +00:00
class ReplConsoleClient final : public JS::ConsoleClient {
public:
ReplConsoleClient(JS::Console& console)
: ConsoleClient(console)
{
}
LibJS+WebContent+js: Bring console.clear() to spec This is identical to before, since we don't have "group stacks" yet, but clear() now uses ThrowCompletionOr.
2021-12-08 19:24:17 +00:00
virtual void clear() override
js: Customise the behaviour of JS::Console with ReplConsoleClient This also makes our JavaScript tests not fail.
2020-05-04 14:09:05 +00:00
{
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
out("\033[3J\033[H\033[2J");
LibJS+WebContent+Browser+js: Implement console.group() methods This implements: - console.group() - console.groupCollapsed() - console.groupEnd() In the Browser, we use `<details>` for the groups, which is not actually implemented yet, so groups are always open. In the REPL, groups are non-interactive, but still indent any output. This looks weird since the console prompt and return values remain on the far left, but this matches what Node does so it's probably fine. :^) I expect `console.group()` is not used much outside of browsers.
2021-12-22 12:32:15 +00:00
m_group_stack_depth = 0;
js: Customise the behaviour of JS::Console with ReplConsoleClient This also makes our JavaScript tests not fail.
2020-05-04 14:09:05 +00:00
fflush(stdout);
}
LibJS: Implement console.assert()
2021-04-18 15:08:14 +00:00
LibJS+WebContent+Browser+js: Implement console.group() methods This implements: - console.group() - console.groupCollapsed() - console.groupEnd() In the Browser, we use `<details>` for the groups, which is not actually implemented yet, so groups are always open. In the REPL, groups are non-interactive, but still indent any output. This looks weird since the console prompt and return values remain on the far left, but this matches what Node does so it's probably fine. :^) I expect `console.group()` is not used much outside of browsers.
2021-12-22 12:32:15 +00:00
virtual void end_group() override
js: Customise the behaviour of JS::Console with ReplConsoleClient This also makes our JavaScript tests not fail.
2020-05-04 14:09:05 +00:00
{
LibJS+WebContent+Browser+js: Implement console.group() methods This implements: - console.group() - console.groupCollapsed() - console.groupEnd() In the Browser, we use `<details>` for the groups, which is not actually implemented yet, so groups are always open. In the REPL, groups are non-interactive, but still indent any output. This looks weird since the console prompt and return values remain on the far left, but this matches what Node does so it's probably fine. :^) I expect `console.group()` is not used much outside of browsers.
2021-12-22 12:32:15 +00:00
if (m_group_stack_depth > 0)
m_group_stack_depth--;
}
// 2.3. Printer(logLevel, args[, options]), https://console.spec.whatwg.org/#printer
virtual JS::ThrowCompletionOr<JS::Value> printer(JS::Console::LogLevel log_level, PrinterArguments arguments) override
{
LibJS+Userland: Port the JS Console object and direct callers to String
2023-02-10 16:40:52 +00:00
auto indent = TRY_OR_THROW_OOM(*g_vm, String::repeated(' ', m_group_stack_depth * 2));
LibJS+WebContent+Browser+js: Implement console.group() methods This implements: - console.group() - console.groupCollapsed() - console.groupEnd() In the Browser, we use `<details>` for the groups, which is not actually implemented yet, so groups are always open. In the REPL, groups are non-interactive, but still indent any output. This looks weird since the console prompt and return values remain on the far left, but this matches what Node does so it's probably fine. :^) I expect `console.group()` is not used much outside of browsers.
2021-12-22 12:32:15 +00:00
LibJS+WebContent+js: Bring console.trace() to spec The spec very kindly defines `Printer` as accepting "Implementation-specific representations of printable things such as a stack trace or group." for the `args`. We make use of that here by passing the `Trace` itself to `Printer`, instead of having to produce a representation of the stack trace in advance and then pass that to `Printer`. That both avoids the hassle of tracking whether the data has been html-encoded or not, and means clients don't have to implement the whole `trace()` algorithm, but only the code needed to output the trace.
2021-12-10 13:48:38 +00:00
if (log_level == JS::Console::LogLevel::Trace) {
auto trace = arguments.get<JS::Console::Trace>();
LibJS+Userland: Port the JS Console object and direct callers to String
2023-02-10 16:40:52 +00:00
JS::ThrowableStringBuilder builder(*g_vm);
LibJS+WebContent+js: Bring console.trace() to spec The spec very kindly defines `Printer` as accepting "Implementation-specific representations of printable things such as a stack trace or group." for the `args`. We make use of that here by passing the `Trace` itself to `Printer`, instead of having to produce a representation of the stack trace in advance and then pass that to `Printer`. That both avoids the hassle of tracking whether the data has been html-encoded or not, and means clients don't have to implement the whole `trace()` algorithm, but only the code needed to output the trace.
2021-12-10 13:48:38 +00:00
if (!trace.label.is_empty())
LibJS+Userland: Port the JS Console object and direct callers to String
2023-02-10 16:40:52 +00:00
MUST_OR_THROW_OOM(builder.appendff("{}\033[36;1m{}\033[0m\n", indent, trace.label));
LibJS+WebContent+js: Bring console.trace() to spec The spec very kindly defines `Printer` as accepting "Implementation-specific representations of printable things such as a stack trace or group." for the `args`. We make use of that here by passing the `Trace` itself to `Printer`, instead of having to produce a representation of the stack trace in advance and then pass that to `Printer`. That both avoids the hassle of tracking whether the data has been html-encoded or not, and means clients don't have to implement the whole `trace()` algorithm, but only the code needed to output the trace.
2021-12-10 13:48:38 +00:00
for (auto& function_name : trace.stack)
LibJS+Userland: Port the JS Console object and direct callers to String
2023-02-10 16:40:52 +00:00
MUST_OR_THROW_OOM(builder.appendff("{}-> {}\n", indent, function_name));
LibJS+WebContent+js: Bring console.trace() to spec The spec very kindly defines `Printer` as accepting "Implementation-specific representations of printable things such as a stack trace or group." for the `args`. We make use of that here by passing the `Trace` itself to `Printer`, instead of having to produce a representation of the stack trace in advance and then pass that to `Printer`. That both avoids the hassle of tracking whether the data has been html-encoded or not, and means clients don't have to implement the whole `trace()` algorithm, but only the code needed to output the trace.
2021-12-10 13:48:38 +00:00
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
outln("{}", builder.string_view());
LibJS+WebContent+js: Bring console.trace() to spec The spec very kindly defines `Printer` as accepting "Implementation-specific representations of printable things such as a stack trace or group." for the `args`. We make use of that here by passing the `Trace` itself to `Printer`, instead of having to produce a representation of the stack trace in advance and then pass that to `Printer`. That both avoids the hassle of tracking whether the data has been html-encoded or not, and means clients don't have to implement the whole `trace()` algorithm, but only the code needed to output the trace.
2021-12-10 13:48:38 +00:00
return JS::js_undefined();
js: Customise the behaviour of JS::Console with ReplConsoleClient This also makes our JavaScript tests not fail.
2020-05-04 14:09:05 +00:00
}
LibJS: Implement console.assert()
2021-04-18 15:08:14 +00:00
LibJS+WebContent+Browser+js: Implement console.group() methods This implements: - console.group() - console.groupCollapsed() - console.groupEnd() In the Browser, we use `<details>` for the groups, which is not actually implemented yet, so groups are always open. In the REPL, groups are non-interactive, but still indent any output. This looks weird since the console prompt and return values remain on the far left, but this matches what Node does so it's probably fine. :^) I expect `console.group()` is not used much outside of browsers.
2021-12-22 12:32:15 +00:00
if (log_level == JS::Console::LogLevel::Group || log_level == JS::Console::LogLevel::GroupCollapsed) {
auto group = arguments.get<JS::Console::Group>();
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
outln("{}\033[36;1m{}\033[0m", indent, group.label);
LibJS+WebContent+Browser+js: Implement console.group() methods This implements: - console.group() - console.groupCollapsed() - console.groupEnd() In the Browser, we use `<details>` for the groups, which is not actually implemented yet, so groups are always open. In the REPL, groups are non-interactive, but still indent any output. This looks weird since the console prompt and return values remain on the far left, but this matches what Node does so it's probably fine. :^) I expect `console.group()` is not used much outside of browsers.
2021-12-22 12:32:15 +00:00
m_group_stack_depth++;
return JS::js_undefined();
}
LibWeb+LibJS: Format Console arguments with JS::Print Instead of just calling JS::Value::to_string_without_side_effects() when printing values to the console, have all the console clients use the same JS::Print that the REPL does to print values. This method leaves some things to be desired as far as OOM hardening goes, however. We should be able to create a String in a way that doesn't OOM on failure so hard.
2023-01-08 17:42:26 +00:00
auto output = TRY(generically_format_values(arguments.get<JS::MarkedVector<JS::Value>>()));
LibJS+js: Disable console debug messages outside Serenity only for `js` Previously we would disable console debug messages on all non Serenity platforms as it caused double printing on lagom `js`. This patch limits this to the `js` utility, allowing LibWeb to print debug messages regardless of the operating system :^)
2022-10-15 20:38:31 +00:00
#ifdef AK_OS_SERENITY
LibJS+WebContent+js: Reimplement console.log() and friends to spec This implements the Logger and Printer abstract operations defined in the console spec, and stubs out the Formatter AO. These are then used for the "output a categorized log message" functions.
2021-12-10 12:26:25 +00:00
m_console.output_debug_message(log_level, output);
LibJS+js: Disable console debug messages outside Serenity only for `js` Previously we would disable console debug messages on all non Serenity platforms as it caused double printing on lagom `js`. This patch limits this to the `js` utility, allowing LibWeb to print debug messages regardless of the operating system :^)
2022-10-15 20:38:31 +00:00
#endif
LibJS+WebContent+js: Reimplement console.log() and friends to spec This implements the Logger and Printer abstract operations defined in the console spec, and stubs out the Formatter AO. These are then used for the "output a categorized log message" functions.
2021-12-10 12:26:25 +00:00
switch (log_level) {
case JS::Console::LogLevel::Debug:
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
outln("{}\033[36;1m{}\033[0m", indent, output);
LibJS+WebContent+js: Reimplement console.log() and friends to spec This implements the Logger and Printer abstract operations defined in the console spec, and stubs out the Formatter AO. These are then used for the "output a categorized log message" functions.
2021-12-10 12:26:25 +00:00
break;
case JS::Console::LogLevel::Error:
LibJS+WebContent+js: Bring console.assert() to spec
2021-12-08 19:43:29 +00:00
case JS::Console::LogLevel::Assert:
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
outln("{}\033[31;1m{}\033[0m", indent, output);
LibJS+WebContent+js: Reimplement console.log() and friends to spec This implements the Logger and Printer abstract operations defined in the console spec, and stubs out the Formatter AO. These are then used for the "output a categorized log message" functions.
2021-12-10 12:26:25 +00:00
break;
case JS::Console::LogLevel::Info:
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
outln("{}(i) {}", indent, output);
LibJS+WebContent+js: Reimplement console.log() and friends to spec This implements the Logger and Printer abstract operations defined in the console spec, and stubs out the Formatter AO. These are then used for the "output a categorized log message" functions.
2021-12-10 12:26:25 +00:00
break;
case JS::Console::LogLevel::Log:
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
outln("{}{}", indent, output);
LibJS+WebContent+js: Reimplement console.log() and friends to spec This implements the Logger and Printer abstract operations defined in the console spec, and stubs out the Formatter AO. These are then used for the "output a categorized log message" functions.
2021-12-10 12:26:25 +00:00
break;
case JS::Console::LogLevel::Warn:
LibJS+WebContent+js: Bring console.count[Reset]() to spec The `CountReset` log level is displayed as a warning, since the message is always to warn that the counter doesn't exist. This is also in line with the table at https://console.spec.whatwg.org/#loglevel-severity
2021-12-08 19:12:06 +00:00
case JS::Console::LogLevel::CountReset:
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
outln("{}\033[33;1m{}\033[0m", indent, output);
LibJS+WebContent+js: Reimplement console.log() and friends to spec This implements the Logger and Printer abstract operations defined in the console spec, and stubs out the Formatter AO. These are then used for the "output a categorized log message" functions.
2021-12-10 12:26:25 +00:00
break;
default:
js: Make console.log() print to stdout again This was broken in 84502f53b5dcd7ffe347269fc1cece777a61a305.
2022-11-28 13:30:20 +00:00
outln("{}{}", indent, output);
LibJS+WebContent+js: Reimplement console.log() and friends to spec This implements the Logger and Printer abstract operations defined in the console spec, and stubs out the Formatter AO. These are then used for the "output a categorized log message" functions.
2021-12-10 12:26:25 +00:00
break;
}
return JS::js_undefined();
}
LibJS+WebContent+Browser+js: Implement console.group() methods This implements: - console.group() - console.groupCollapsed() - console.groupEnd() In the Browser, we use `<details>` for the groups, which is not actually implemented yet, so groups are always open. In the REPL, groups are non-interactive, but still indent any output. This looks weird since the console prompt and return values remain on the far left, but this matches what Node does so it's probably fine. :^) I expect `console.group()` is not used much outside of browsers.
2021-12-22 12:32:15 +00:00
private:
int m_group_stack_depth { 0 };
js: Customise the behaviour of JS::Console with ReplConsoleClient This also makes our JavaScript tests not fail.
2020-05-04 14:09:05 +00:00
};
js: Port to LibMain :^) This wasn't particularly difficult, and there's not much use for the nicer interface yet either. While unveil() is of limited use in js(1) as it should be able to open arbitrary files, I feel like we should be able to add a pledge() call.
2021-11-22 19:25:30 +00:00
ErrorOr<int> serenity_main(Main::Arguments arguments)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
{
Userland: Link directly against LibUnicodeData where needed This is partially a revert of commits: 10a8b6d4116c6a627a6c189154af032f69b29c21 561b67a1add82538502ef2f5733f1d86718898ad Rather than adding the prot_exec pledge requried to use dlopen(), we can link directly against LibUnicodeData in applications that we know need that library. This might make the dlopen() dance a bit unnecessary. The same purpose might now be fulfilled with weak symbols. That can be revisted next, but for now, this at least removes the potential security risk of apps like the Browser having prot_exec privileges.
2021-12-29 18:10:12 +00:00
TRY(Core::System::pledge("stdio rpath wpath cpath tty sigaction"));
js: Use pledge() It is now no longer possible to make network connections from a hijacked js(1) :^)
2021-11-22 20:41:58 +00:00
LibJS+js: Add a debug option (js -g) to GC after every allocation This is very useful for discovering collector bugs.
2020-03-16 18:18:46 +00:00
bool gc_on_every_allocation = false;
js: Turn on live syntax highlighting by default
2020-04-30 20:37:50 +00:00
bool disable_syntax_highlight = false;
js: Add --disable-debug-output option Added option to disable debug output (eg unhandled Promise rejections) to the JS repl.
2023-06-04 14:54:50 +00:00
bool disable_debug_printing = false;
js: Add --use-test262-global option Add --use-test262-global option to expose the test262 global object instead of normal script object.
2023-06-06 08:23:34 +00:00
bool use_test262_global = false;
js: Add a command line argument to evaluate a string as a script For example: $ js -c "console.log(42)" 42
2022-02-09 12:53:49 +00:00
StringView evaluate_script;
Userland: Use Core::ArgsParser's Vector<StringView> API everywhere ...and remove the Vector<String> variant since there are no remaining users of this API.
2021-11-26 21:32:37 +00:00
Vector<StringView> script_paths;
js: Run with the JavaScript bytecode VM by default The AST interpreter is still available behind a new `--ast` flag.
2023-07-25 16:12:18 +00:00
bool use_ast_interpreter = false;
js: Take the script file as a command-line argument Now that we have the beginnings of a parser, let's take the script to run as a command-line argument and move all the test scripts into /home/anon/js :^) To run a script, simply use "js": $ js my-script.js To get an AST dump before execution, you can use "js -A"
2020-03-12 09:51:41 +00:00
Core::ArgsParser args_parser;
Userland: Write some '--help' descriptions where appropriate
2020-12-05 15:22:58 +00:00
args_parser.set_general_help("This is a JavaScript interpreter.");
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
args_parser.add_option(s_dump_ast, "Dump the AST", "dump-ast", 'A');
LibJS: Move global "should dump bytecode" flag into LibJS This will allow us to trigger bytecode executable dumps when generating bytecode inside LibJS as well, not just in clients like js and test-js.
2021-10-24 11:34:46 +00:00
args_parser.add_option(JS::Bytecode::g_dump_bytecode, "Dump the bytecode", "dump-bytecode", 'd');
js: Run with the JavaScript bytecode VM by default The AST interpreter is still available behind a new `--ast` flag.
2023-07-25 16:12:18 +00:00
args_parser.add_option(use_ast_interpreter, "Enable JavaScript AST interpreter (deprecated)", "ast", 0);
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 15:30:37 +00:00
args_parser.add_option(s_as_module, "Treat as module", "as-module", 'm');
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
args_parser.add_option(s_print_last_result, "Print last result", "print-last-result", 'l');
js: Add a command line argument to evaluate a string as a script For example: $ js -c "console.log(42)" 42
2022-02-09 12:53:49 +00:00
args_parser.add_option(s_strip_ansi, "Disable ANSI colors", "disable-ansi-colors", 'i');
js: Add command line flag for disabling source line hints
2021-11-23 21:02:19 +00:00
args_parser.add_option(s_disable_source_location_hints, "Disable source location hints", "disable-source-location-hints", 'h');
LibJS+js: Add a debug option (js -g) to GC after every allocation This is very useful for discovering collector bugs.
2020-03-16 18:18:46 +00:00
args_parser.add_option(gc_on_every_allocation, "GC on every allocation", "gc-on-every-allocation", 'g');
js: Turn on live syntax highlighting by default
2020-04-30 20:37:50 +00:00
args_parser.add_option(disable_syntax_highlight, "Disable live syntax highlighting", "no-syntax-highlight", 's');
js: Add --disable-debug-output option Added option to disable debug output (eg unhandled Promise rejections) to the JS repl.
2023-06-04 14:54:50 +00:00
args_parser.add_option(disable_debug_printing, "Disable debug output", "disable-debug-output", {});
js: Add a command line argument to evaluate a string as a script For example: $ js -c "console.log(42)" 42
2022-02-09 12:53:49 +00:00
args_parser.add_option(evaluate_script, "Evaluate argument as a script", "evaluate", 'c', "script");
js: Add --use-test262-global option Add --use-test262-global option to expose the test262 global object instead of normal script object.
2023-06-06 08:23:34 +00:00
args_parser.add_option(use_test262_global, "Use test262 global ($262)", "use-test262-global", {});
Userland: Allow multiple files to be run by js js only accepted a single script file to run before this. With this patch, multiple scripts can be run in the same execution environment, allowing the user to specify a "preamble script" to be executed before the main script.
2021-06-16 13:55:34 +00:00
args_parser.add_positional_argument(script_paths, "Path to script files", "scripts", Core::ArgsParser::Required::No);
Everywhere: Use ArgsParser::parse() with Main::Arguments directly Use the updated API everywhere we are currently manually passing in `arguments.argc` and `arguments.argv`.
2021-11-23 00:03:05 +00:00
args_parser.parse(arguments);
js: Take the script file as a command-line argument Now that we have the beginnings of a parser, let's take the script to run as a command-line argument and move all the test scripts into /home/anon/js :^) To run a script, simply use "js": $ js my-script.js To get an AST dump before execution, you can use "js -A"
2020-03-12 09:51:41 +00:00
js: Run with the JavaScript bytecode VM by default The AST interpreter is still available behind a new `--ast` flag.
2023-07-25 16:12:18 +00:00
JS::Bytecode::Interpreter::set_enabled(!use_ast_interpreter);
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 13:59:18 +00:00
js: Turn on live syntax highlighting by default
2020-04-30 20:37:50 +00:00
bool syntax_highlight = !disable_syntax_highlight;
js: Add --disable-debug-output option Added option to disable debug output (eg unhandled Promise rejections) to the JS repl.
2023-06-04 14:54:50 +00:00
AK::set_debug_enabled(!disable_debug_printing);
js: Convert `s_history_path` to String and propagate errors
2023-02-04 04:04:32 +00:00
s_history_path = TRY(String::formatted("{}/.js-history", Core::StandardPaths::home_directory()));
LibJS: Propagate errors from VM creation
2023-03-17 14:44:47 +00:00
g_vm = TRY(JS::VM::create());
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
g_vm->enable_default_host_import_module_dynamically_hook();
LibJS: Implement ImportCall and HostImportModuleDynamically This allows us to load modules from scripts. This can be dangerous as it can load arbitrary files. Because of that it fails and throws by default. Currently, only js and JavaScriptTestRunner enable the default hook. This also adds tests to test-js which test module code. Because we form a spec perspective can't "enter" a module this is the easiest way to run tests without having to modify test-js to have special cases for modules. To specify modules in test-js we use the extension '.mjs' this is to ensure the files are not executed. We do still want to lint these files so the prettier scripts have changed to look for '.mjs' files as well.
2022-01-18 18:39:36 +00:00
js: Add --disable-debug-output option Added option to disable debug output (eg unhandled Promise rejections) to the JS repl.
2023-06-04 14:54:50 +00:00
if (!disable_debug_printing) {
// NOTE: These will print out both warnings when using something like Promise.reject().catch(...) -
// which is, as far as I can tell, correct - a promise is created, rejected without handler, and a
// handler then attached to it. The Node.js REPL doesn't warn in this case, so it's something we
// might want to revisit at a later point and disable warnings for promises created this way.
g_vm->on_promise_unhandled_rejection = [](auto& promise) {
warn("WARNING: A promise was rejected without any handlers");
warn(" (result: ");
(void)print(promise.result(), PrintTarget::StandardError);
warnln(")");
};
g_vm->on_promise_rejection_handled = [](auto& promise) {
warn("WARNING: A handler was added to an already rejected promise");
warn(" (result: ");
(void)print(promise.result(), PrintTarget::StandardError);
warnln(")");
};
}
js: Interrupt running script or REPL evaluation when receiving SIGINT
2020-04-24 16:59:16 +00:00
OwnPtr<JS::Interpreter> interpreter;
LibJS+Everywhere: Remove VM::exception() and most related functions This commit removes all exception related code: Remove VM::exception(), VM::throw_exception() etc. Any leftover throw_exception calls are moved to throw_completion. The one method left is clear_exception() which is now a no-op. Most of these calls are just to clear whatever exception might have been thrown when handling a Completion. So to have a cleaner commit this will be removed in a next commit. It also removes the actual Exception and TemporaryClearException classes since these are no longer used. In any spot where the exception was actually used an attempt was made to preserve that behavior. However since it is no longer tracked by the VM we cannot access exceptions which were thrown in previous calls. There are two such cases which might have different behavior: - In Web::DOM::Document::interpreter() the on_call_stack_emptied hook used to print any uncaught exception but this is now no longer possible as the VM does not store uncaught exceptions. - In js the code used to be interruptable by throwing an exception on the VM. This is no longer possible but was already somewhat fragile before as you could happen to throw an exception just before a VERIFY.
2022-02-07 14:12:41 +00:00
// FIXME: Figure out some way to interrupt the interpreter now that vm.exception() is gone.
js: Interrupt running script or REPL evaluation when receiving SIGINT
2020-04-24 16:59:16 +00:00
js: Add a command line argument to evaluate a string as a script For example: $ js -c "console.log(42)" 42
2022-02-09 12:53:49 +00:00
if (evaluate_script.is_empty() && script_paths.is_empty()) {
js: Throw a regular SyntaxError for errors from the parser
2020-05-14 15:29:24 +00:00
s_print_last_result = true;
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
interpreter = JS::Interpreter::create<ReplObject>(*g_vm);
LibJS: Move Console ownership from GlobalObject to ConsoleObject GlobalObject is now a regular object with no special properties :^)
2022-08-28 13:20:06 +00:00
auto& console_object = *interpreter->realm().intrinsics().console_object();
ReplConsoleClient console_client(console_object.console());
console_object.console().set_client(console_client);
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
interpreter->heap().set_should_collect_on_every_allocation(gc_on_every_allocation);
js: Fix that auto completion of properties failed For this we store the global environment in which we can do a lookup for the references variable. This is probably not entirely as the spec would specify as we would need a running executing context at all times you do things with references. Fixes #10281
2021-10-03 11:17:33 +00:00
auto& global_environment = interpreter->realm().global_environment();
LibLine: Use Core::EventLoop for outer read loop This commit changes LibLine's internal structure to work in an event loop, and as a result, also switches it to being a Core::Object.
2020-05-26 10:34:39 +00:00
s_editor = Line::Editor::construct();
js: Convert `s_history_path` to String and propagate errors
2023-02-04 04:04:32 +00:00
s_editor->load_history(s_history_path.to_deprecated_string());
Userland: Install LibLine's signal handlers in the JS repl
2020-04-11 09:09:10 +00:00
signal(SIGINT, [](int) {
LibLine: Ignore interrupts unless actively editing 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.
2020-04-28 20:01:22 +00:00
if (!s_editor->is_editing())
sigint_handler();
js: Convert `s_history_path` to String and propagate errors
2023-02-04 04:04:32 +00:00
s_editor->save_history(s_history_path.to_deprecated_string());
Userland: Install LibLine's signal handlers in the JS repl
2020-04-11 09:09:10 +00:00
});
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
s_editor->on_display_refresh = [syntax_highlight](Line::Editor& editor) {
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
auto stylize = [&](Line::Span span, Line::Style styles) {
if (syntax_highlight)
editor.stylize(span, styles);
};
editor.strip_styles();
js: Follow Serenity C++ naming conventions
2020-04-26 14:19:30 +00:00
size_t open_indents = s_repl_line_level;
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
LibJS: Fix incorrect token column values (#2401) - initializing m_line_column to 1 in the lexer results in incorrect column values in tokens on the first line of input. - not incrementing m_line_column when EOF is reached results in an incorrect column value on the last token.
2020-05-26 17:00:30 +00:00
auto line = editor.line();
JS::Lexer lexer(line);
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
bool indenters_starting_line = true;
for (JS::Token token = lexer.next(); token.type() != JS::TokenType::Eof; token = lexer.next()) {
js: Use CodepointOriented spans and use the codepoint length of token We were previously using byte-oriented spans. This would work if not for token.line_column() being in codepoints.
2021-09-01 16:13:53 +00:00
auto length = Utf8View { token.value() }.length();
js: Use token offset for highlighting instead of column offset This makes it work correctly with multiline inputs as well.
2022-03-06 07:02:15 +00:00
auto start = token.offset();
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
auto end = start + length;
if (indenters_starting_line) {
if (token.type() != JS::TokenType::ParenClose && token.type() != JS::TokenType::BracketClose && token.type() != JS::TokenType::CurlyClose) {
indenters_starting_line = false;
} else {
--open_indents;
JS Repl: Add live syntax highlighting This patchset adds live syntax highlighting to the js repl. It is turned off by default and can be enabled via the -s flag.
2020-04-05 14:03:12 +00:00
}
}
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
switch (token.category()) {
case JS::TokenCategory::Invalid:
js: Use CodepointOriented spans and use the codepoint length of token We were previously using byte-oriented spans. This would work if not for token.line_column() being in codepoints.
2021-09-01 16:13:53 +00:00
stylize({ start, end, Line::Span::CodepointOriented }, { Line::Style::Foreground(Line::Style::XtermColor::Red), Line::Style::Underline });
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
break;
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
case JS::TokenCategory::Number:
js: Use CodepointOriented spans and use the codepoint length of token We were previously using byte-oriented spans. This would work if not for token.line_column() being in codepoints.
2021-09-01 16:13:53 +00:00
stylize({ start, end, Line::Span::CodepointOriented }, { Line::Style::Foreground(Line::Style::XtermColor::Magenta) });
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
break;
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
case JS::TokenCategory::String:
js: Use CodepointOriented spans and use the codepoint length of token We were previously using byte-oriented spans. This would work if not for token.line_column() being in codepoints.
2021-09-01 16:13:53 +00:00
stylize({ start, end, Line::Span::CodepointOriented }, { Line::Style::Foreground(Line::Style::XtermColor::Green), Line::Style::Bold });
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
break;
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
case JS::TokenCategory::Punctuation:
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
break;
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
case JS::TokenCategory::Operator:
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
break;
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
case JS::TokenCategory::Keyword:
switch (token.type()) {
case JS::TokenType::BoolLiteral:
case JS::TokenType::NullLiteral:
js: Use CodepointOriented spans and use the codepoint length of token We were previously using byte-oriented spans. This would work if not for token.line_column() being in codepoints.
2021-09-01 16:13:53 +00:00
stylize({ start, end, Line::Span::CodepointOriented }, { Line::Style::Foreground(Line::Style::XtermColor::Yellow), Line::Style::Bold });
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
break;
default:
js: Use CodepointOriented spans and use the codepoint length of token We were previously using byte-oriented spans. This would work if not for token.line_column() being in codepoints.
2021-09-01 16:13:53 +00:00
stylize({ start, end, Line::Span::CodepointOriented }, { Line::Style::Foreground(Line::Style::XtermColor::Blue), Line::Style::Bold });
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
break;
}
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
break;
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
case JS::TokenCategory::ControlKeyword:
js: Use CodepointOriented spans and use the codepoint length of token We were previously using byte-oriented spans. This would work if not for token.line_column() being in codepoints.
2021-09-01 16:13:53 +00:00
stylize({ start, end, Line::Span::CodepointOriented }, { Line::Style::Foreground(Line::Style::XtermColor::Cyan), Line::Style::Italic });
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
break;
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 21:28:59 +00:00
case JS::TokenCategory::Identifier:
js: Use CodepointOriented spans and use the codepoint length of token We were previously using byte-oriented spans. This would work if not for token.line_column() being in codepoints.
2021-09-01 16:13:53 +00:00
stylize({ start, end, Line::Span::CodepointOriented }, { Line::Style::Foreground(Line::Style::XtermColor::White), Line::Style::Bold });
Everywhere: Add break after the last case label before `default` We already do this in most places, so the style should be consistent. Also, Clang does not like it, as this could cause an unexpected compile error if some statements are added to the default label or a new label is added above it.
2021-07-05 17:17:08 +00:00
break;
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
default:
break;
}
}
js: Use String in `prompt_for_level()` and `read_next_piece()`
2023-02-04 03:08:42 +00:00
editor.set_prompt(prompt_for_level(open_indents).release_value_but_fixme_should_propagate_errors().to_deprecated_string());
JS repl: Fix indentation when a line starts with '})]'
2020-04-09 03:30:45 +00:00
};
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
js: Fix that auto completion of properties failed For this we store the global environment in which we can do a lookup for the references variable. This is probably not entirely as the spec would specify as we would need a running executing context at all times you do things with references. Fixes #10281
2021-10-03 11:17:33 +00:00
auto complete = [&interpreter, &global_environment](Line::Editor const& editor) -> Vector<Line::CompletionSuggestion> {
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
auto line = editor.line(editor.cursor());
JS::Lexer lexer { line };
enum {
Initial,
CompleteVariable,
CompleteNullProperty,
CompleteProperty,
} mode { Initial };
StringView variable_name;
StringView property_name;
LibLine: Display suggestions and cycle between them With extra color (tm) This commit also patches the users of LibLine to properly use the new API
2020-04-11 14:32:15 +00:00
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
// we're only going to complete either
// - <N>
// where N is part of the name of a variable
// - <N>.<P>
// where N is the complete name of a variable and
// P is part of the name of one of its properties
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
auto js_token = lexer.next();
for (; js_token.type() != JS::TokenType::Eof; js_token = lexer.next()) {
switch (mode) {
case CompleteVariable:
switch (js_token.type()) {
case JS::TokenType::Period:
// ...<name> <dot>
mode = CompleteNullProperty;
break;
default:
// not a dot, reset back to initial
mode = Initial;
break;
}
break;
case CompleteNullProperty:
if (js_token.is_identifier_name()) {
// ...<name> <dot> <name>
mode = CompleteProperty;
property_name = js_token.value();
} else {
mode = Initial;
}
break;
case CompleteProperty:
// something came after the property access, reset to initial
case Initial:
Utilities: Make the js REPL autocomplete correctly handle `new Ident` Previously, `new` was being recognised as an identifier, which was preventing this from working.
2021-07-15 22:03:09 +00:00
if (js_token.type() == JS::TokenType::Identifier) {
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
// ...<name>...
mode = CompleteVariable;
variable_name = js_token.value();
} else {
mode = Initial;
}
break;
}
}
bool last_token_has_trivia = js_token.trivia().length() > 0;
if (mode == CompleteNullProperty) {
mode = CompleteProperty;
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
property_name = ""sv;
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
last_token_has_trivia = false; // <name> <dot> [tab] is sensible to complete.
}
if (mode == Initial || last_token_has_trivia)
return {}; // we do not know how to complete this
LibLine: Allow suggestions to have trailing trivia strings 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
2020-04-19 14:02:28 +00:00
Vector<Line::CompletionSuggestion> results;
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
Everywhere: Pass AK::StringView by value
2021-11-10 23:55:02 +00:00
Function<void(JS::Shape const&, StringView)> list_all_properties = [&results, &list_all_properties](JS::Shape const& shape, auto property_pattern) {
js: Convert to east const
2021-07-06 22:58:50 +00:00
for (auto const& descriptor : shape.property_table()) {
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-08 04:38:46 +00:00
if (!descriptor.key.is_string())
continue;
auto key = descriptor.key.as_string();
if (key.view().starts_with(property_pattern)) {
Line::CompletionSuggestion completion { key, Line::CompletionSuggestion::ForSearch };
js: Ignore property attributes for completion 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.
2020-05-02 15:01:09 +00:00
if (!results.contains_slow(completion)) { // hide duplicates
AK+Everywhere: Rename String to DeprecatedString 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 :^)
2022-12-04 18:02:33 +00:00
results.append(DeprecatedString(key));
LibLine+Userland: Make suggestion offsets per-suggestion This allows the user to modify different parts of the input with different suggestions.
2022-02-28 13:58:47 +00:00
results.last().invariant_offset = property_pattern.length();
LibLine: Display suggestions and cycle between them With extra color (tm) This commit also patches the users of LibLine to properly use the new API
2020-04-11 14:32:15 +00:00
}
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
}
}
js: Convert to east const
2021-07-06 22:58:50 +00:00
if (auto const* prototype = shape.prototype()) {
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
list_all_properties(prototype->shape(), property_pattern);
}
};
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
switch (mode) {
case CompleteProperty: {
js: Prefix global variables with 'g_' This makes it much clearer that they are, in fact, global variables. Also avoids name shadowing issues, especially with 'vm'.
2022-06-30 18:34:38 +00:00
auto reference_or_error = g_vm->resolve_binding(variable_name, &global_environment);
js: Remove uses of TRY_OR_DISCARD() Slightly more verbose, but that's the last user of TRY_OR_DISCARD gone!
2022-01-04 21:54:31 +00:00
if (reference_or_error.is_error())
return {};
LibJS: Replace GlobalObject with VM in Reference AOs [Part 6/19]
2022-08-21 14:39:13 +00:00
auto value_or_error = reference_or_error.value().get_value(*g_vm);
js: Remove uses of TRY_OR_DISCARD() Slightly more verbose, but that's the last user of TRY_OR_DISCARD gone!
2022-01-04 21:54:31 +00:00
if (value_or_error.is_error())
return {};
auto variable = value_or_error.value();
VERIFY(!variable.is_empty());
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
if (!variable.is_object())
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
break;
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
LibJS: Port Value::to_object() to NonnullGCPtr
2023-04-13 13:26:41 +00:00
auto const object = MUST(variable.to_object(*g_vm));
js: Convert to east const
2021-07-06 22:58:50 +00:00
auto const& shape = object->shape();
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
list_all_properties(shape, property_name);
break;
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
}
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
case CompleteVariable: {
LibJS+LibWeb: Reduce use of GlobalObject as an intermediary - Prefer VM::current_realm() over GlobalObject::associated_realm() - Prefer VM::heap() over GlobalObject::heap() - Prefer Cell::vm() over Cell::global_object() - Prefer Wrapper::vm() over Wrapper::global_object() - Inline Realm::global_object() calls used to access intrinsics as they will later perform a direct lookup without going through the global object
2022-08-22 18:00:49 +00:00
auto const& variable = interpreter->realm().global_object();
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
list_all_properties(variable.shape(), variable_name);
js: Allow for completion of lexically declared variables This does require us to have a method which lists all the bindings in a declarative environment which is not in the spec.
2021-10-03 11:20:15 +00:00
LibJS: Use Vector instead of HashMap in DeclarativeEnvironment Constructing the HashMap in DeclarativeEnvironment was by far the most expensive thing when making JavaScript function calls. As it turns out, we don't really need this to be a HashMap in the first place, as lookups are cached (by EnvironmentCoordinate) after the first access, so after that we were not even looking in the HashMap, going directly to the bindings Vector instead. This reduces function_declaration_instantiation() from 16% to 9% when idling in "Biolab Disaster". It also reduces has_binding() from 3% to 1% on the same content. With these changes, we now actually get to idle a little bit between game frames on my machine. :^)
2022-03-07 13:02:37 +00:00
for (auto const& name : global_environment.declarative_record().bindings()) {
LibLine+Userland: Make suggestion offsets per-suggestion This allows the user to modify different parts of the input with different suggestions.
2022-02-28 13:58:47 +00:00
if (name.starts_with(variable_name)) {
js: Allow for completion of lexically declared variables This does require us to have a method which lists all the bindings in a declarative environment which is not in the spec.
2021-10-03 11:20:15 +00:00
results.empend(name);
LibLine+Userland: Make suggestion offsets per-suggestion This allows the user to modify different parts of the input with different suggestions.
2022-02-28 13:58:47 +00:00
results.last().invariant_offset = variable_name.length();
}
js: Allow for completion of lexically declared variables This does require us to have a method which lists all the bindings in a declarative environment which is not in the spec.
2021-10-03 11:20:15 +00:00
}
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
break;
}
default:
Everywhere: Rename ASSERT => VERIFY (...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.
2021-02-23 19:42:32 +00:00
VERIFY_NOT_REACHED();
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
}
Userland: Add primitive autocomplete to the JS repl This patch adds primitive support for autocompletion in the JS repl, it only supports completing global names and properties on variables :^)
2020-04-11 09:09:55 +00:00
return results;
};
LibLine: Unify completion hooks and adapt its users LibLine should ultimately not care about what a "token" means in the context of its user, so force the user to split the buffer itself. This also allows the users to pick up contextual clues as well, since they have to lex the line themselves. This commit pacthes Shell and the JS repl to better handle completions, so certain wrong behaviours are now corrected as well: - JS repl can now complete "Object . getOw<tab>" - Shell can now complete "echo | ca<tab>" and paths inside strings
2020-05-19 04:12:01 +00:00
s_editor->on_tab_complete = move(complete);
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
TRY(repl(*interpreter));
js: Convert `s_history_path` to String and propagate errors
2023-02-04 04:04:32 +00:00
s_editor->save_history(s_history_path.to_deprecated_string());
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
} else {
js: Add --use-test262-global option Add --use-test262-global option to expose the test262 global object instead of normal script object.
2023-06-06 08:23:34 +00:00
if (use_test262_global) {
interpreter = JS::Interpreter::create<JS::Test262::GlobalObject>(*g_vm);
} else {
interpreter = JS::Interpreter::create<ScriptObject>(*g_vm);
}
LibJS: Move Console ownership from GlobalObject to ConsoleObject GlobalObject is now a regular object with no special properties :^)
2022-08-28 13:20:06 +00:00
auto& console_object = *interpreter->realm().intrinsics().console_object();
ReplConsoleClient console_client(console_object.console());
console_object.console().set_client(console_client);
Userland/JS: Extend the global object when using a REPL When we enter a repl we call initialize_global_object on our custom ReplObject in order to expose REPL specific features. Specifically: help(), exit(code), and load("file1.js", "file2.js", "fileEtc.js").
2020-04-01 19:20:32 +00:00
interpreter->heap().set_should_collect_on_every_allocation(gc_on_every_allocation);
js: Interrupt running script or REPL evaluation when receiving SIGINT
2020-04-24 16:59:16 +00:00
signal(SIGINT, [](int) {
sigint_handler();
});
Userland: Allow multiple files to be run by js js only accepted a single script file to run before this. With this patch, multiple scripts can be run in the same execution environment, allowing the user to specify a "preamble script" to be executed before the main script.
2021-06-16 13:55:34 +00:00
StringBuilder builder;
js: Add a command line argument to evaluate a string as a script For example: $ js -c "console.log(42)" 42
2022-02-09 12:53:49 +00:00
StringView source_name;
if (evaluate_script.is_empty()) {
if (script_paths.size() > 1)
warnln("Warning: Multiple files supplied, this will concatenate the sources and resolve modules as if it was the first file");
for (auto& path : script_paths) {
LibCore: Move Stream-based file into the `Core` namespace
2023-02-09 02:02:46 +00:00
auto file = TRY(Core::File::open(path, Core::File::OpenMode::Read));
LibCore: Rename `Stream::read_all` to `read_until_eof` This generally seems like a better name, especially if we somehow also need a better name for "read the entire buffer, but not the entire file" somewhere down the line.
2022-12-11 16:49:00 +00:00
auto file_contents = TRY(file->read_until_eof());
js: Add a command line argument to evaluate a string as a script For example: $ js -c "console.log(42)" 42
2022-02-09 12:53:49 +00:00
auto source = StringView { file_contents };
js: Convert non-UTF-8 encoded files to UTF-8 before parsing
2022-04-03 13:31:04 +00:00
if (Utf8View { file_contents }.validate()) {
builder.append(source);
} else {
LibTextCodec+Everywhere: Return Optional<Decoder&> from `decoder_for()`
2023-02-17 17:45:08 +00:00
auto decoder = TextCodec::decoder_for("windows-1252"sv);
VERIFY(decoder.has_value());
js: Convert non-UTF-8 encoded files to UTF-8 before parsing
2022-04-03 13:31:04 +00:00
LibTextCodec+Everywhere: Port Decoders to new Strings
2023-02-17 20:15:10 +00:00
auto utf8_source = TRY(TextCodec::convert_input_to_utf8_using_given_decoder_unless_there_is_a_byte_order_mark(*decoder, source));
js: Convert non-UTF-8 encoded files to UTF-8 before parsing
2022-04-03 13:31:04 +00:00
builder.append(utf8_source);
}
js: Add a command line argument to evaluate a string as a script For example: $ js -c "console.log(42)" 42
2022-02-09 12:53:49 +00:00
}
source_name = script_paths[0];
} else {
builder.append(evaluate_script);
source_name = "eval"sv;
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
js: Display a warning if multiple files are given Also instead of making a frankenstein path with all the paths combined just take the first one, this is needed for resolving modules.
2022-01-17 17:47:32 +00:00
// We resolve modules as if it is the first file
LibJS: Include executable name in bytecode dumps
2021-10-24 12:33:56 +00:00
LibJS+js: Move the value print implementation to LibJS And make it capable of printing to any Core::Stream. This is useful on its own and can be used in a number of places, so move it out and make it available as JS::print().
2022-11-22 04:20:51 +00:00
if (!TRY(parse_and_run(*interpreter, builder.string_view(), source_name)))
LibJS: Do not execute scripts with parse errors This adds missing checks in several LibJS consumers.
2020-04-13 00:05:21 +00:00
return 1;
Userland: Implement JS REPL If you invoke `js` without a script path, it will now enter REPL mode, where you input commands one by one and immediately get each one interpreted in one shared interpreter. We support multi-line commands in case we detect you have unclosed braces or parens or brackets.
2020-03-25 22:10:29 +00:00
}
js: Exercise the garbage collector a little bit
2020-03-08 18:59:59 +00:00
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
return 0;
}
Reference in a new issue Copy permalink