lust-lang

Identifying the real root cause and the real bottleneck Hello, Thank you for you project. But I believe it hunts the problem from the wrong bottleneck. The real bottleneck, why rust compiler is very slow that it need to recompile the entire universe to build any simple project inside a clean ci/cd. What is the root cause for this problem? IMHO and many others agree the reason that there is no shared libraries in rust. When you type , , or ..etc. the package manager does not grab the source and compile it. in many cases it finds a pre-compiled shared library (/) so if I want to create a simple alert dialog popup using gpui-kit rust compiler would be asking itself how to draw a pixel, how to talk to the OS, ..etc. when if I'm doing the same with c++ or python there will be (from rpm package) and the compiler in my project will be just talking to it. even if you just want to center a div, your rust compiler will be asking itself how to parse yaml, how do printers work, ...etc. Proposal a subset of rust the can be packaged in c-like .so and a wrapper A subset that do the following features for the exposed/exported parts (internal non-exposed non-exported parts can do whatever): operates on register-sized primitives immutable compound inputs but with register-sized primitives returns in-place mutations of inputs caller-allocated (heap or stack), caller-owned memory but this is not enough and too restrictive? I don't think it's, a compiler or a machine can transfer any functions into two steps, one that allocates the output and one that do the job let's take something like a numpy matrix multiplication of A[kl] and B[lm] = C[km] this function need to allocate km the return the size the need to be allocated for C, it's allocated in caller scope and ownership and lifecycle and it's under the responsibility of the caller to free C while does no allocation, only in-place operations or do stack allocations that the caller does not need to care about. since is simple it can be placed in .so this separation of matmul into two parts can be done by a compiler and into .so from developer point of view this separation and glue can be done under the hood without he noticing.

What was wrong These programs build with rustc but rejects them with L0104 "no method ": I hit this through , and through a I'm adding in a follow-up PR. Priority queues are a common pattern in generated code. Why There were two separate causes, both in : 1. The Copy test looked only at the impl header. skips a written for a Copy type, on purpose: glue copies the bits, and that can differ from a written clone with side effects. It decided "Copy" by matching the header without checking . So counted as Copy, its written Clone was skipped, and nothing else supplied one. The fix also asks of the concrete instance, and checks the bounds. A non-Copy instance now takes the written-impl path, which is what rustc does. 2. A Copy had no Clone. For this case only, glue now treats as Clone exactly when 's glue clone exists. That is sound because core's written clone is (library/core/src/cmp.rs), and for a Copy it equals the bitwise copy. What I deliberately did not change A Copy type whose own written has a side effect is still rejected, as before. Two new reject tests pin this, for a plain struct and for one wrapped in . I tried two broader fixes first and dropped both because each broke rule zero: calling for every ADT in : rustc calls a side-effecting written clone through and , and that program then printed differently; on : this changed behaviour. Tests produces output identical to rustc. It includes a side-effecting written clone called through and . and both expect L0104. : 94 passed, 0 failed. : 2214 passed. The 16 failures are the same set as on unpatched ; they come from my local rustc 1.97, not from this change. I did not run the full gate locally. Speed No measurable change. All three PRs were measured together () against on Linux x86-64, with the profile and . The edit-check, build and RSS rows stay within run-to-run noise. Cold check and no-op check were then re-measured with A/B interleaving: Context: this came out of using lust as a millisecond oracle in a code-search loop, where a mutator proposes Rust and lust checks and runs it. Rejecting a program that rustc accepts costs a whole candidate there, so these false rejections were the friction points worth fixing. 🤖 Generated with Claude Code https://claude.ai/code/session_014xSb5dyAap5fysHAnvyZ3i

What this does The diagnostics JSON already has an field, but nothing filled it: had no callers. This PR fills it for one of the most common errors in machine-written Rust, mixing integer types: Each such error now carries a two-part edit that turns into . This is the real output for the line: When an edit is means safe to apply without review. Here that means the cast cannot change a value: and never count as lossless, because their width depends on the target. Where it applies L0110 mismatches with integer types on both sides: annotated , call argument, return value. L0113 on a binary operator or compound assignment (, , …). The cast goes on the right operand. Shifts are left alone: Rust accepts any integer type as a shift amount, so there is nothing to fix. Tests gets a new section, 1b, with three checks: 1. A program with widening and narrowing mismatches gets a two-part edit on every error, and follows the table above. 2. Applying every edit gives a program that accepts. 3. rustc accepts it too; this check is skipped if rustc is not installed. : 28 passed, 0 failed. The existing assertion, on an L0304 borrow error, is unchanged and still holds. : 2214 passed. The 16 failures are the same set as on unpatched ; they come from my local rustc 1.97, not from this change. I did not run the full gate locally. Speed No measurable change. All three PRs were measured together () against on Linux x86-64, with the profile and . The edit-check, build and RSS rows stay within run-to-run noise. Cold check and no-op check were then re-measured with A/B interleaving: Why For an agent or search loop, "here is the exact fix, and it is safe" is worth more than a message. In my loop runs, mixed integer types were a recurring reason that otherwise-good candidates got rejected; each one cost a model round-trip to repair, and an edit removes that round-trip. 🤖 Generated with Claude Code https://claude.ai/code/session_014xSb5dyAap5fysHAnvyZ3i