Dominic

I'm not sure I understand the CI failure - it looks like it's something to do with docgen. The error says it's a problem with wasi not supporting `hasEnvVarConstants`, but...

Or is it something specifically to do with bootstrapping? It looks like `build-debug/zig2` is the executable that's being used during the failure.

Looks like `ZIG_DEBUG_COLOR` is referenced in 3 others files: ``` ~/S/z/src (master) > rg ZIG_DEBUG_COLOR lib/build_runner.zig 285: .escape_codes => try builder.env_map.put("ZIG_DEBUG_COLOR", "1"), lib/std/io/tty.zig 16: } else if (process.hasEnvVarConstant("ZIG_DEBUG_COLOR")) { test/src/StackTrace.zig...

whoops

I'll be happy with that. You won't be able to force the windows specific way of colouring, but I don't know if that's something you actually ever want to do.

> btw I noticed that LLVM has a way to mark arbitrary code paths as cold: https://llvm.org/docs/LangRef.html#assume-operand-bundles I find the section on assume operator bundles unclear - one interpretation is...

> ... but you should probably add a setter function that `dupePath`s it though. Done. I think this is probably merge-ready then, unless I should rebase onto current master first.

> I think alignment of the columns across benchmarks is actually really helpful for viewing... > > Could we limit the number of sigfigs shown for numbers so we know...

Looks like the CI ran with a version of zig that is 5 commits too old to include the `fmtDuration` changes.

> I believe this was solved by #30 For the most part yes. There might be a few things to take/rework from here e.g. if we want the range columns...