This now means that when trying to open a folder, one can click on
the folder and press open instead of having to actually step into
the desired folder. Of course, it also means it won't let you open
non-directories anymore.
For one, viewing a variable who's type contained a subprogram will
no longer crash HackStudio. Additionally, the variable view will
handle invalid enum values gracefully now, fixing another crash.
Finally, deeply nested (nest count > 1) structures will have their
memory addresses properly set, fixing the final crash I found.
HackStudio's debugger instance has its source root property updated
when switching projects, and breakpoints will properly canonicalize
their file paths as the Debugger now expects.
Creating a file while having a file or directory selected will now
create the file under the selected directory, or in same directory as
a selected file.
Creating directories works the same way.
Right click -> Open on selected files will now open the selected files.
Deleting selected files will now delete the selected files.
As suggested by sagefarrenholz this was accomplished by adding a private
function HackStudioWidget::selected_file_paths() that returns a
Vector<String> of the current project tree selection.
Function HackStudioWidget::selected_file_names() is removed due to not being used.
This type represents templatized names, and replaces our previous use
of 'TemplatizedType' and 'TemplatizedFunctionCall'.
Also, we now parse function calls as secondary expressions.
We now restart the language server transparently if it crashes.
If the language server crashes too frequently (current threshold is
twice within 3 seconds), we give up and will not attempt to restart it
again. HackStudio will still work fine, but features that depend on the
language server will not function.
To support this change we use a new class, 'ServerConnectionWrapper',
that holds the actual ServerConnection and is responsible for restarting
the language-server if it crashes.
Closes#5574.
- FileDB::get() now returns nullptr if the file is not in the FileDB
- Added FileDB::get_or_create_from_filesystem()
- Added FileDB::add() version that receives that file's content as a
parameter
This fixes an issue were "Find in Files" would not use the up-to-date
content of a file with unsaved changes.
The issue existed because 'FindInFilesWidget' uses
Project::for_each_text_file, which retrieves files by their absolute
path. However, when a file is opened in an Editor, it is created with
a relative path.
This caused us to store two ProjectFile objects that refer to the same
file - one with a relative path and one with an absolute path.
HackStudio keeps a map that stores the different ServerConnection
instances we have open.
Previously, that map was indexed by a project's root path.
This did not make much sense because we only support opening a single
project with each instance of the HackStudio program.
We now index the different ServerConnections by the language name, which
allows us to support talking to multiple language-servers in the same
project (e.g C++ and Shell).
This also fixes an issue where if you first opened a Shell file, and
then a C++ file in the same project, then C++ language-server features
would not work.
This makes them available for use by other language servers.
Also as a bonus, update the Shell language server to discover some
symbols and add go-to-definition functionality :^)
The Locator now keeps a cache of the declared symbol in a document.
The language client updates that cache whenever it gets an update from
the language server about declared symbols.
This allows searching for symbol declarations in the Locator, in
addition to file names.
Closes#5478
(...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.
