-
marker
An experimental linting interface for Rust. Let's make custom lints a reality (by rust-marker)
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
reduze
Discontinued Zig program reduction is upstream in compiler due to various parser + formatter interactions.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Check out this, which aims to implement said stable interface!
I think with Cranelift's investment into an e-graph based optimizer (https://github.com/bytecodealliance/rfcs/blob/main/accepted/cranelift-egraph.md) they are well positioned to have quite competitive performance as a backend.
In 2022, we merged a project that has a huge impact on compile times in the right scenarios: incremental compilation. The basic idea is to cache the result of compiling individual functions, keyed on a hash of the IR. This way, when the compiler input only changes slightly – which is a common occurrence when developing or debugging a program – most of the compilation can reuse cached results. The actual design is much more subtle and interesting: we split the IR into two parts, a “stencil” and “parameters”, such that compilation only depends on the stencil (and this is enforced at the type level in the compiler). The cache records the stencil-to-machine-code compilation. The parameters can be applied to the machine code as “fixups”, and if they change, they do not spoil the cache. We put things like function-reference relocations and debug source locations in the parameters, because these frequently change in a global but superficial way (i.e., a mass renumbering) when modifying a compiler input. We devised a way to fuzz this framework for correctness by mutating a function and comparing incremental to from-scratch compilation, and so far have not found any miscompilation bugs.
If you have any user stories, that could be interesting for marker, I'd appreciate a user story in the design repo. I'm also open to answer any potential questions :)
Would such a project make it possible to have a faster rust repl? We can use evcxr, but it definitely doesn't feel first-class.
Maybe, with the caveat that coordination/synchronization in a distributed build is a non-trivial overhead for Rust builds under buck2.
If not: Editing the source file may lead to silent formatting jumps, which invalidate your AST. This rules out in-memory AST patching and any tracking of how the AST has been modified (you need to track AST to source locations for that). I've written about that in my another very unfinished reduction project.