I just encountered "Reduce Cognitive Load" in a comment on Hacker News
and it fits the acronym very well, I'm going to keep a list of possible
meanings of the name "RCL".
Previously we named the file "build.rcl", but now that that is the
default name for "rcl build", let's name the Ninja meta build file
"ninja.rcl". Also, clarify that Make is able to use the depfiles too,
just in a way that I personally try to stay far away from.
As expected, the golden tests fail to run under Nix because the test
directory is not writable. And it's better to not write in my opinion,
let's not hack that and have a dry run output mode.
For now the output format is not structured, this is good enough for the
thests. It could be nice to do structured output in RCL format, but we
can do that later if needed.
I don't like this distinction that in the build file, we don't
implicitly add a newline, but on the command line we do. But making
users specify a trailing newline on the command line is annoying. So
then the RCL build spec will have to match the CLI, and append the
newline. But then empty string cannot be the default, so let's accept
null too.
So I can highlight stuff on my blog as long as there is no highlighting
in Pandoc/Skylighting. With the change to MarkupString, this was really
easy to do!
This fixes a longstanding issue where reporting errors that we have to
blame on just the document's result in general got blamed on its full
span, which is often a comment and not the offending value. Now we blame
it on the inner body expression, which is more natural.
At first I thought, “but a single-element collection should always fit,
right?” And sure it fits, but then I reformatted a larger experimental
config I have, including some GitHub Actions, and it turns out that
sometimes I prefer even single-element litst to be tall. Black is right
about this. I should be less opinionated, leave it to the user.
The fuzzer now discovered a non-idempotency in the formatter, in case
there is a non-code prefix for the condition. This has something to do
with the space between "if" and the condition, there is no separator
there, whatever follows goes on the same line, which is usually not the
case.
For evaluation everything works fine, but how do you format this? We can
try to repair it, but it's hard. A solution that sidesteps all this is
to restrict what kind of expressions we can have after an if. Just don't
allow statements and ifs there. We don't lose any expressivity, if you
want that it still works, just put parens around it. With parens it is
also possible to format the expression properly, e.g.
if (
// Comments are fine, everything is indented here, etc.
condition
):
then_value
else
else_value
Oh, and unrelated, I think I am convinced that I want the colon after
"else" back. But let's do that in a follow-up. Or maybe it can be
optional but the formatter always puts it there?
The implementation of this forces propagating spans in more places,
which ended up being a drive-by fix for one place where spans were
computed incorrectly. This fix shows up in the golden tests.
So now I have the two primary ones, "fuzz_source" and "fuzz_smith". Now
I just need to make something to feed the outputs of the smith into the
fuzz_source corpus.
I have this "smith" fuzzer now, but I also want to have a "smith" tool
to inspect the corpus, having two similar binaries is confusing, and
also having files with the same name is confusing in editors that don't
show the full path. So rename all fuzz binaries to start with fuzz_.
Selecting the Rust version here is harder than it needs to be, it
creates confusing errors when it’s not installed, also fetching the Git
ref fails for some people, and I have to keep the version number up to
date ... better to just not have this, people should git clone + cargo
build.
