Skip to content

Commit 74a92bb

Browse files
authored
Merge pull request #381 from nikomatsakis/main
Updates to finalize RFC test
2 parents 6de60e6 + 44ddbf7 commit 74a92bb

File tree

6 files changed

+34
-47
lines changed

6 files changed

+34
-47
lines changed

src/2025h2/README.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,7 @@ This period we have (((#FLAGSHIP GOALS))) flagship goals, broken out into four t
3030

3131
* [Beyond the `&`](#beyond-the-), making it possible to create user-defined smart pointers that are as ergonomic as Rust's built-in references `&`.
3232
* [Unblocking dormant traits](#unblocking-dormant-traits), extending the core capabilities of Rust's trait system to unblock long-desired features for language interop, lending iteration, and more.
33-
* [Flexible, fast(er) Rust builds](#flexible-faster-rust-builds), making Rust's builds fasterand improving support for specialized build scenarios like embedded usage and sanitizers.
33+
* [Flexible, fast(er) compilation](#flexible-faster-rust-compilation), making it faster to build Rust programs and improving support for specialized build scenarios like embedded usage and sanitizers.
3434
* [Higher-level Rust](#higher-level-rust), making higher-level usage patterns in Rust easier.
3535

3636
### "Beyond the `&`"
@@ -53,11 +53,11 @@ Rust's trait system is one of its most powerful features, but it has a number of
5353
* The work to [expand Rust's `Sized` hierarchy](./scalable-vectors.md) will permit us to express types that are neither `Sized` nor `?Sized`, such as extern types (which have no size) or Arm's Scalable Vector Extension (which have a size that is known at runtime, but not compilation time). This goal builds on [RFC #3729][] and [RFC #3838][], authored in previous project goal periods.
5454
* [In-place initialization](./in-place-initialization.md) allows creating structs and values that are tied to a particular place in memory. While useful directly for projects doing advanced C interop, it also unblocks expanding `dyn Trait` to support for `async fn` and `-> impl Trait` methods, as compiling such methods requires the ability for the callee to return a future whose size is not known to the caller.
5555

56-
### "Flexible, fast(er) Rust builds"
56+
### "Flexible, fast(er) compilation"
5757

58-
(((FLAGSHIP GOALS: Flexible, fast(er) Rust builds)))
58+
(((FLAGSHIP GOALS: Flexible, fast(er) compilation)))
5959

60-
The "Flexible, fast(er) Rust builds" initiative focuses on improving Rust's build system to better serve both specialized use cases and everyday development workflows:
60+
The "Flexible, fast(er) compilation" initiative focuses on improving Rust's build system to better serve both specialized use cases and everyday development workflows:
6161

6262
* We are improving compilation performance through (1) [parallel compilation in the compiler front-end](./parallel-front-end.md), which delivers 20-30% faster builds, and (2) [making the Cranelift backend production-ready for development use](./production-ready-cranelift.md), offering roughly 20% faster code generation compared to LLVM for debug builds.
6363
* We are working to [stabilize a core MVP of the `-Zbuild-std` feature](./build-std.md), which allows developers to rebuild the standard library from source with custom compiler flags. This unblocks critical use cases for embedded developers and low-level projects like Rust for Linux, while also enabling improvements like using sanitizers with the standard library or building `std` with debug information.

src/2025h2/autoreborrow-traits.md

Lines changed: 22 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -61,6 +61,26 @@ An improvement is needed.
6161
- Gather feedback from users, especially `reborrow` crate users.
6262
- Implement nightly support for recursive reborrowing.
6363

64+
65+
The basic idea of autoreborrowing is simple enough: when a reborrowable type is encountered at a coercion
66+
site, attempt a reborrow operation. The `Pin<&mut T>` special-case in the
67+
compiler already exists and could probably be reimagined to rely on a `Reborrow` trait.
68+
69+
Complications arise when reborrowing becomes recursive: if a `struct X { a: A, b: B }` contains two
70+
reborrowable types `A` and `B`, then we'd want the reborrow of `X` to be performed "piecewise". As an
71+
example, the following type should, upon reborrow, only invalidate any values that depend on the `'a` lifetime while any values dependent on the `'b` lifetime should still be usable as normal.
72+
73+
```rust
74+
struct X<'a, 'b> {
75+
a: &'a mut A,
76+
b: &'b B,
77+
}
78+
```
79+
80+
To enable this, reborrowing needs to be defined as a recursive operation but what the "bottom-case" is, that
81+
is the question. One option would be to use `!Copy + Reborrow` fields, another would use core marker types
82+
like `PhantomExclusive<'a>` and `PhantomShared<'b>` to discern the difference.
83+
6484
### The "shiny future" we are working towards
6585

6686
`Pin` ergonomics group should be able to get rid of special-casing of `Pin` reborrowing in rustc.
@@ -90,48 +110,12 @@ Users of `reborrow` crate and similar should be enabled to move to core solution
90110

91111
## Ownership and team asks
92112

113+
93114
| Task | Owner(s) or team(s) | Notes |
94115
| ---------------------------- | -------------------- | ------------------------------------------------------------------ |
95116
| Discussion and moral support | ![Team][] [lang] | Normal RFC process |
96117
| Standard reviews | ![Team][] [compiler] | Trait-impl querying in rustc to replace `Pin<&mut T>` special case |
118+
| Lang-team experiment | ![Team][] [lang] | allows coding pre-RFC; only for trusted contributors |
97119
| Do the work | @aapoalas | |
98120

99-
### Experiment with Reborrow trait design
100-
101-
The basic idea of autoreborrowing is simple enough: when a reborrowable type is encountered at a coercion
102-
site, attempt a reborrow operation.
103-
104-
Complications arise when reborrowing becomes recursive: if a `struct X { a: A, b: B }` contains two
105-
reborrowable types `A` and `B`, then we'd want the reborrow of `X` to be performed "piecewise". As an
106-
example, the following type should, upon reborrow, only invalidate any values that depend on the `'a` lifetime while any values dependent on the `'b` lifetime should still be usable as normal.
107-
108-
```rust
109-
struct X<'a, 'b> {
110-
a: &'a mut A,
111-
b: &'b B,
112-
}
113-
```
114-
115-
To enable this, reborrowing needs to be defined as a recursive operation but what the "bottom-case" is, that
116-
is the question. One option would be to use `!Copy + Reborrow` fields, another would use core marker types
117-
like `PhantomExclusive<'a>` and `PhantomShared<'b>` to discern the difference.
118-
| Task | Owner(s) or team(s) | Notes |
119-
| -------------------- | ---------------------------------- | ------------------------------------------------------------------- |
120-
| Lang-team experiment | ![Team][] [lang] | allows coding pre-RFC; only for trusted contributors |
121-
| Author RFC | *Goal point of contact, typically* | |
122-
| RFC decision | ![Team][] [lang] | |
123-
| RFC secondary review | ![Team][] [types] | request bandwidth from a second team, most features don't need this |
124-
125-
### Seek feedback for an RFC based on experiment
126-
127-
A basic autoreborrowing feature should not be too complicated: the `Pin<&mut T>` special-case in the
128-
compiler already exists and could probably be reimagined to rely on a `Reborrow` trait.
129-
130-
| Task | Owner(s) or team(s) | Notes |
131-
| --------------------------------- | ---------------------------------- | ----- |
132-
| Implementation | *Goal point of contact, typically* | |
133-
| Standard reviews | ![Team][] [compiler] | |
134-
| Design meeting | ![Team][] [lang] | |
135-
| Author call for testing blog post | *Goal point of contact, typically* | |
136-
137121
## Frequently asked questions

src/2025h2/build-std.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44
| :------------------ | :--------------------------------- |
55
| Point of contact | @davidtwco |
66
| Status | Proposed |
7-
| Flagship | Flexible, fast(er) Rust builds |
7+
| Flagship | Flexible, fast(er) compilation |
88
| Zulip channel | N/A |
99
| Tracking issue | [rust-lang/rust-project-goals#274] |
1010
| [cargo] champion | @ehuss |

src/2025h2/field-projections.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -100,6 +100,9 @@ Have field projections available in stable Rust.
100100
| Design meeting | ![Team][] [lang] | Possibly more than one required as well as discussions on zulip. |
101101
| Lang-team experiment | ![Team][] [lang] | @dingxiangfei2009, @BennoLossin |
102102
| Author RFC | @BennoLossin | |
103-
| RFC secondary review | ![Team][] [types] | might be a good idea? |
104-
| RFC decision | ![Team][] [lang] | |
103+
105104
## Frequently asked questions
105+
106+
### Why not push for RFC decision?
107+
108+
[The design is still too early to expect a final decision on the RFC.](https://github.com/rust-lang/rfcs/pull/3849#discussion_r2311807884)

src/2025h2/parallel-front-end.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44
| :--------------- | ---------------------------------------- |
55
| Point of contact | @SparrowLii |
66
| Status | Proposed |
7-
| Flagship | Flexible, fast(er) Rust builds |
7+
| Flagship | Flexible, fast(er) compilation |
88
| Tracking issue | [rust-lang/rust-project-goals#121] |
99
| See also | [rust-lang/rust#113349] |
1010
| Zulip channel | [#t-compiler/wg-parallel-rustc][channel] |

src/2025h2/production-ready-cranelift.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44
| :--------------- | ------------------------------ |
55
| Point of contact | @folkertdev |
66
| Status | Proposed |
7-
| Flagship | Flexible, fast(er) Rust builds |
7+
| Flagship | Flexible, fast(er) compilation |
88
| Tracking issue | |
99
| Zulip channel | |
1010

0 commit comments

Comments
 (0)