|
| 1 | +# Publish first version of StableMIR on crates.io |
| 2 | + |
| 3 | +| Metadata | | |
| 4 | +| -------- |--------------------------------| |
| 5 | +| Owner(s) | @celinval | |
| 6 | +| Teams | [project-stable-mir] | |
| 7 | +| Status | Proposed | |
| 8 | + |
| 9 | +## Summary |
| 10 | + |
| 11 | +Publish StableMIR crate(s) to crates.io to allow tool developers to create applications on the top of the Rust compiler, |
| 12 | +and extract code information from a compiled Rust crate and their dependencies without using compiler internal APIs. |
| 13 | + |
| 14 | +## Motivation |
| 15 | + |
| 16 | +In the past couple of years we have introduced a more stable API, named StableMIR, to the Rust compiler |
| 17 | +to enable tool developers to analyze and extract information from compiled Rust crates without directly depending on compiler internals. |
| 18 | +By publishing StableMIR crate(s) to crates.io, we can provide a reliable interface that enables developers to build analysis tools, |
| 19 | +development environments, and other applications that work with Rust code while being insulated from internal compiler changes. |
| 20 | + |
| 21 | +Publishing these crates through crates.io will make them easily accessible to the broader Rust community |
| 22 | +and establish a foundation for building a robust ecosystem of development tools. |
| 23 | +This will benefit the entire Rust ecosystem by enabling developers to create sophisticated tooling such as static analyzers, |
| 24 | +linters, and development environments that can work reliably across different Rust compiler versions. |
| 25 | +Besides stability, users will be able to rely on semantic versioning to track and adapt to changes, |
| 26 | +reducing the existing maintenance burden for these developers. |
| 27 | + |
| 28 | +### The status quo |
| 29 | + |
| 30 | +In the past couple of years we have introduced a more stable API, named StableMIR, to the Rust compiler. |
| 31 | +This API provides tool developers more stability and predictability, reducing the maintenance cost, |
| 32 | +as well as providing a smaller surface API to reduce the ramp-up time for new developers. |
| 33 | + |
| 34 | +However, StableMIR consumption model is still similar to any other internal compiler crate. |
| 35 | +It doesn't have any explicit version, and it must be imported using an `extern crate` statement. |
| 36 | + |
| 37 | +### The next 6 months |
| 38 | + |
| 39 | +The first task is to restructure the relationship between `stable-mir` and `rustc_smir` crates, |
| 40 | +eliminating existing dependencies on the `stable-mir` crate. |
| 41 | + |
| 42 | +This will be followed by forking the `stable-mir` crate into its own repository, |
| 43 | +where we'll implement CI jobs designed to detect any breaking changes that might occur due to compiler updates. |
| 44 | + |
| 45 | +Once the structural changes are complete, we'll shift our attention to documentation and publication. |
| 46 | +This includes creating comprehensive developer documentation that covers maintenance procedures for both crates, |
| 47 | +ensuring future maintainers have clear guidelines for updates and compatibility management. |
| 48 | + |
| 49 | +The final step will be publishing the newly refactored and documented version of stable-mir to crates.io, |
| 50 | +making it readily available for tool developers in the Rust ecosystem. |
| 51 | + |
| 52 | +### The "shiny future" we are working towards |
| 53 | + |
| 54 | +By establishing a stable and well-documented interface, |
| 55 | +we would like to empower developers to build a rich tooling ecosystem for Rust that can be |
| 56 | +maintained in parallel with the Rust compiler's development. |
| 57 | + |
| 58 | +This parallel development model ensures that tools can evolve alongside Rust itself, |
| 59 | +fostering innovation and reducing bottlenecks. |
| 60 | + |
| 61 | +## Design axioms |
| 62 | + |
| 63 | +- Enable tool developers to implement sophisticated analysis with low maintenance cost. |
| 64 | +- Do not compromise the development and innovation speed of the rust compiler. |
| 65 | +- Crates should follow semantic versioning. |
| 66 | + |
| 67 | +## Ownership and team asks |
| 68 | + |
| 69 | + |
| 70 | +| Subgoal | Owner(s) or team(s) | Notes | |
| 71 | +|------------------------------|--------------------------------|-------| |
| 72 | +| Refactor crates dependencies | | | |
| 73 | +| ↳ Implementation | @celinval | | |
| 74 | +| ↳ Standard reviews | ![Team][] [project-stable-mir] | | |
| 75 | +| Fork configuration | Help needed | | |
| 76 | +| Documentation | Help needed | | |
| 77 | +| Publish crate | @celinval | | |
| 78 | + |
| 79 | +### Definitions |
| 80 | + |
| 81 | +Definitions for terms used above: |
| 82 | + |
| 83 | +* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated. |
| 84 | + |
| 85 | +## Frequently asked questions |
0 commit comments