Using a portable minimal markdown dependency (such as cmark [1]) I think markdown can be quite a low barrier here. I personally do similar to what you have described on my blog, with an additional cmark conversion and find it quite simple [2].
Zig had a similar issue which I made an MR to fix. I didn't actually notice Rust had the same issue but that's probably just my forgotten knowledge with how the vec! macros expand when nested.
I wouldn't assume that just because Andrew has written the proposal it will be accepted. There have been plenty of times where proposals from Andrew have been rejected and/or reworked.
The sub-items of this task are still valuable to complete even if this overarching proposal were declined. Most of them are not being completed as a prerequisite for this proposal. There are benefits gained even without the full removal of LLVM.
I can really respect the really wide-reaching views and goals of Andrew with zig and in proposals like this, even if I don't agree.
There is a recent draft PR [1] to merge this into the zig compiler itself.
LLVM is being placed as a an optional component in the future [2]. Using arocc to fill this gap would mean that seamless C compilation could still be done, without LLVM being involved.
This is a nice write-up. Since zig has quite extensive compile-time functionality, one drawback is it is often easy to miss untested branches, especially for non-native targets if they are not regularly tested. It would be quite beneficial to be able to combine coverage reports from different targets to get a full picture of the tested code.
I have previously used kcov [1] to perform coverage testing which due to zig having good DWARF debugging information worked with no fanfare. However, I'm not too familiar with the shortcomings of this method vs. the more fully instrumented binary approach provided.
Cool, I wasn't aware of kcov. Looks like kcov sets breakpoints on every line to get its coverage information, which seems like it'd probably be comparable to what callgrind is doing. The difference would be in execution speed, and after testing kcov, it looks like it wins that handily:
GNATCoverage (Ada-only) has interesting binary coverage capabilities. Qemu trace, valgrind instrumentation, nexus... If interested I built once A gdb-branch-trace script, a pintool to generate the trace or an Intel-PT-based prototype. Dyninst and dynamo rio too. Neat exercise
As an example, xxHash [1] would probably get you an easy 5-10x performance improvement over Blake2b. So there are some easy improvements if the cryptographic requirement is not needed.
The code itself should be up to date for most, but I'm aware of a few examples than need touch-ups. Unfortunately there is a bit more boilerplate compared to other languages for some simple tasks, since Zig requires you to be quite explicit about things (e.g. i/o, memory allocation).
Regarding the rejection of '\r', there is the intention for `zig fmt` to handle these minor issues and reformat code as needed which hopefully reduces this barrier. There was a long issue regarding hard tabs with discussion here: https://github.com/ziglang/zig/issues/544
[1] https://github.com/commonmark/cmark
[2] https://github.com/tiehuis/tiehuis.github.io/blob/38b0fd58a2...