Since readdir() actually gives us the file type, we don't have
to stat it again to know whether it's a directory! This means that
'find /' can process the majority of files without ever calling
stat() on them, simply by reading directories.
In addition, the TypeCommand (-t) can make use of this info too,
so, for instance, a 'find / -t d' does not need to stat anything
either.
This gives us a final huge speedup :^)
We have multiple commands that are implemented in terms of stat.
Let's cache the stat in FileData after we query it once.
This gives us another large speed-up :^)
While Core::DirIterator is nice C++ API, we want more low-level
control here. In particular, we want to open the directory using
openat(), to also not pay the cost of re-traversing the path
components we have already resolved previously.
This gives us another nice speedup :^)
Also, in the future commits this will allow us to make use of more
data from the returned struct dirent, to speed things up even further.
This speeds things up noticeably :^)
The idea here is that a directory fd is a way to hold onto
the results of path resolution that the kernel has already done
for us. This way we don't ask the kernel to resolve the same
parent directories over and over.
I noticed while testing `find` that the output of `find` contains extra
forward slashes if the root path has a trailing slash. This patch fixes
that issue by passing the root path through LexicalPath before
proceeding.
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 *
(...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.
