They were previously stored inside the Locator widget. I moved them to
the globally visible ProjectDeclarations class so they can also be used
by other widgets.
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.
What I meant for the GUI progress bars to show:
- Bytes copied of the current file
- Files copied of the total set
What it actually showed:
- Bytes copied of the total bytes
- Files copied of the total set
This patch fixes it by showing byte progress of the current file
instead of byte progress of total bytes.
And display the progress of the copy operation in a separate window. :^)
Note that this patch only updates the drag&drop code path to use the new
mechanism. We still have to go through FileManager and make use of this
everywhere.
We also need to support additional operations, like Move, Delete, etc.
Still, this is quite cool! :^)
This is a helper program for FileManager that performs a file operation
in a separate process and reports progress on standard out.
This initial implementation only supports the "Copy" operation and does
not do any detailed error handling.
Previously, when trying to debug variables with more complex
types (such as String), we would crash the debugger simply because
it didn't know how to handle types that were irrelevant anyways.
Now we just skip data we don't yet know how to handle.
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.
GCC determines whether the system's <limits.h> header is usable
and installs a different version of its own <limits.h> header
depending on whether the system header file exists.
If the system header is missing GCC's <limits.h> header does not
include the system header via #include_next.
For this to work we need to install LibC's headers before
attempting to build GCC.
Also, re-running BuildIt.sh "hides" this problem because at that
point the sysroot directory also already has a <limits.h> header
file from the previous build.
The find_last_of implementations were breaking out of the search loop
too early for single-character string views. This caused a crash in
CookieJar setting a cookie on google.com - CookieJar::default_path knew
there was at least one "/" in a string view, but find_last_of returned
nullopt, so dereferencing the optional caused a crash.
Fixes#6273
Setting the year to NumericLimits<unsigned>::max() resulted in the
following datetime: -2-12-31 00:00:00.
Instead, set the latest datetime to the last second of the year 9999.
This should provide some speed up, as currently searches for regions
containing a given address were performed in O(n) complexity, while
this container allows us to do those in O(logn).
This does not affect functionality right now, but it means that the
regions vector will now never have any overlapping regions, which will
allow the use of balance binary search trees instead of a vector in the
future. (since they require keys to be exclusive)
This container is similar to the RedBlackTree container, but instead of
transparently allocating tree nodes on insertion and freeing on removal
this container piggybacks on intrusive node fields in the stored class
This container is based on a balanced binary search tree, and as such
allows for O(logn) worst-case insertion, removal, and search, as well
as O(n) sorted iteration.
Previous a mallocation was marked as 'reachable' when any other
mallocation or memory region had a pointer to that mallocation. However
there could be the situation that two mallocations have pointers to each
other while still being unreachable from anywhere else. They would be
marked as 'reachable' regardless.
This patch replaces the old way of detemining whether a mallocation is
reachable by analyzing the dependencies of the different mallocations
using a graph-approach. Now mallocations are only reachable if pointed
to by other reachable mallocations or other memory regions.
A nice bonus is that this gets rid of a nested for_each_mallocation, so
the complexity of leak finding becomes linear instead of quadratic.
