Skip to content

Commit 71642ed

Browse files
nikomatsakisnikomatsakis
authored
Merge pull request #165 from chorman0773/main
[2025H1] Add T-spec goals
2 parents 1d2f84d + 2b6dc8d commit 71642ed

File tree

2 files changed

+120
-0
lines changed

2 files changed

+120
-0
lines changed

‎src/2025h1/spec-fls-integration.md

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
# Integration of the FLS into the Rust Project
2+
3+
| Metadata | |
4+
| -------- | ------------------------------------------------------------ |
5+
| Owner(s) | Joel Marcey |
6+
| Teams | spec |
7+
| Status | Proposed |
8+
9+
## Summary
10+
11+
Ferrous Systems will be transfering the Ferrocene Language Specification (FLS) to the Rust Project, under the ownership of the Specification Team, or `t-spec`. In the first half of 2025, the Specification team will integrate the FLS, under an appropriate name, into both its design and development processes, and the project as a whole.
12+
13+
## Motivation
14+
15+
The Specification Team has been working for the past year on preparing a specification of Rust. Over this time, the Team has made and began executing several distinct plans to achieve this: creating a new document; modifying the reference; and most recently, agreeing with Ferrous Systems to take ownership of the FLS to support its specification delivery efforts. The current plan is to do the latter two processes in parrallel, and in order to do that effectively the Ferrocene Language Specification needs to be adopted and integrated into the project processes and tooling.
16+
17+
### The status quo
18+
19+
[RFC 3355] describes the goals of the specification as "\[Serving\] the needs of Rust users, such as authors of unsafe Rust code, those working on safety critical Rust software, language designers, maintainers of Rust tooling, and so on," and "Incorporating it in their process for language evolution. For example, the language team could require a new language feature to be included in the specification as a requirement for stabilization."
20+
21+
Presently, the working draft Specification of Rust consists of a modified version of the reference, achieved by adding paragraph identifiers (almost finished), and slowly modifying the content to more normatively describe the language. This may help achieve one of the presented goals for the the specification, namely incorporation into the language evolution process.
22+
However, Ferrous Systems has, over the past 2 years, developed the Ferrocene Language Specification, which has seen adoption in the Safety Critical Space, and a sharp change in the specification would create substantial financial burdens on those early adopters.
23+
24+
Based on more recent discussions and agreements with Ferrous Systems, the Specification Team will be incorporating the the Ferrocene Language Specification as-is into its processes. This will leave us with two documents to maintain, with decisions to make on how they will fit into the Specification delivery process overall.
25+
26+
### The next 6 months
27+
28+
In order to properly integrate the Ferrocene Language Specification, presumably under a different name, the specification team will need to adopt processes surrounding modification, editing, review, and release of the document.
29+
30+
### The "shiny future" we are working towards
31+
32+
The goal is designed to move forward the Rust Specification, in a way that is satisfying to both internal and external consumers, and that makes progress on the overall goals set out in [RFC 3355]. It is also designed to put us in a position for a 2025h2 goal of producing a first useful version of the specification that satisfies those goals, as well as any ancillary work that needs to be done along side the specification itself.
33+
34+
[RFC 3355]: https://rust-lang.github.io/rfcs/3355-rust-spec.html
35+
36+
## Design axioms
37+
38+
The following [design axioms][da] apply:
39+
* Making Decisions Effectively, but Efficiently: When the goal asks the Team to make a decision, the Team should be prepared in advance with the necessary background, and come to consensus based on as much information as is possible, but at the same time, acting with efficiency and alacrity, not spending more time than is necessary on a decision. In particular, the team should not delay discussing a decision more than is necessary.
40+
* Elaborating on the last part, decisions the team are well aware of needing to make should not be deferred once all of the requesite information is available, unless a higher priority decision needs to supplant it.
41+
* Iterative changes are better: When it comes to making modifications, particularily to the FLS, slow and gradual ones should be preferred to sharp, major ones.
42+
43+
[da]: ../about/design_axioms.md
44+
45+
## Ownership and team asks
46+
47+
**Owner:** As the hired specification editor, Joel Marcey will own the overall goal. Connor Horman will also aid in bringing the goal to completion in their role as a Contractor.
48+
49+
Some subgoals list an expected due/completion date. If one is omitted, compeletion by the end of 2025h1 is implied.
50+
51+
52+
| Subgoal | Owner(s) or team(s) | Notes |
53+
| ----------------------------------------------------- | ------------------- | --------------------------------------- |
54+
| Complete Taking Ownership of the FLS | ![Team][] [spec] | Prior to, or shortly into January 2025. |
55+
| Integrate FLS into T-spec processes | ![Team][] [spec] | |
56+
| ↳Review Existing Editorial Standards in the FLS | | End of January 2025 |
57+
| ↳Review Tooling used by the FLS | Connor Horman | End of January 2025 |
58+
| ↳Author Proposal for specifics of FLS integration | Connor Horman | Mid-Late Februrary 2025 |
59+
| ↳Review, iterate, and accept Integration Proposal | ![Team][] [spec] | End of March 2025 |
60+
| ↳Adjust Tooling, as needed | Connor Horman | April 2025 |
61+
| ↳Merge one Chapter from the Reference | Connor Horman | |
62+
| Integrate FLS into release process | ![Team][] [release]| |
63+
| ↳Discuss requirements with T-release | | Februrary 2025 |
64+
| ↳Link tooling used with FLS to the release process | | April 2025 |
65+
| ↳Review of FLS prior to release | | May 2025 |
66+
| ↳Get FLS into a Rust Release | | Rust 1.89 |
67+
68+
69+
## Frequently asked questions
70+

‎src/2025h1/spec-testing.md

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
# Rust Specification Testing
2+
3+
| Metadata | |
4+
| -------- | ------------------------------------------------------------ |
5+
| Owner(s) | Connor Horman |
6+
| Teams | T-spec |
7+
| Status | Proposed |
8+
9+
## Summary
10+
11+
The Rust test suite covers huge portions of the Rust Compiler (`rustc`). To ensure that the content of the Rust specification is correct, and ongoing compliance is validated, Rust tests will be added and linked directly in the specification itself.
12+
13+
## Motivation
14+
15+
The Rust Specification has been authored over the past year by the Specification Team (`t-spec`). The team currently has a generally well-defined path forward on the content for the specification. However, to ensure this text is accurate, there needs to be appropriate tests.
16+
17+
### The status quo
18+
19+
The rust compiler currently has tests for many aspects of the language, specifically tests of language guarantees that will be documented in the specification, and implementation-specific behaviour that is desirable to test for other reasons (including diagnostics and some optimizations). These tests are largely contained in the ui test suite, are disorganized, and are intermingled. Some tests engage both language-guaranteed behaviour and implementation-specific behaviour.
20+
21+
### The next 6 months
22+
23+
New and existing tests will be integrated with the specification through tagging individual tests with paragraph identifiers from the reference or the FLS. In cooperation with the compiler team and the bootstrap team, the test structure will be reorganized to make it more clear which tests are exercising guaranteed aspects of the language and which tests may be exercising chosen details of the Rust Compiler (i.e., `rustc`) implementation.
24+
25+
### The "shiny future" we are working towards
26+
27+
The integration of testing into the specification should:
28+
* Aid Review of the Reference and Specification, by being able to read Rust code that demonstrates and validates the text of those documents,
29+
* Likewise assist readers who may wish to view the implications of a given paragraph in a programmatic manner,
30+
* Aid the development of the Rust Language, and to assist improvements to the processes being considered by the Language Team,
31+
* Aid the development of the Rust Compiler and its test suite as a whole, by improving organization of the test suite, including differentiating between tests of language-level guaranteed behaviour and tests of implementation-specific behaviour, and
32+
* Aid in the use of the Rust Specification in the context of safety-critical development, by providing traceability for the content of the Specification.
33+
34+
35+
## Ownership and team asks
36+
37+
**Owner:** Connor Horman
38+
39+
40+
| Subgoal | Owner(s) or team(s) | Notes |
41+
| -------------------------------- | ------------------- | ---------------------------------------- |
42+
| Determine precise test structure | | |
43+
| ↳Author RFC | Connor Horman | |
44+
| ↳Review RFC | ![Team][] [spec] ![Team][] [compiler] ![Team][bootstrap] ![Team][] [lang] | |
45+
| ↳Move/Extract Tests | Connor Horman | As Needed |
46+
| ↳Annotate Moved Tests | | |
47+
| ↳Author new tests | Connor Horman | |
48+
49+
## Frequently asked questions
50+

0 commit comments

Comments
 (0)