From cbfcbaa9d52b2b547608998e9aa39321720f053e Mon Sep 17 00:00:00 2001 From: Ed Page Date: Thu, 19 Jun 2025 15:11:49 -0500 Subject: [PATCH 1/2] Carry over project goals related to epage This left out open-namespaces as that is more on the compiler side and it would be good for them to carry it over now that they are manning it. --- src/2025h2/cargo-plumbing.md | 159 +++++++++++++++++++++++++++++++++++ src/2025h2/cargo-script.md | 106 +++++++++++++++++++++++ src/2025h2/libtest-json.md | 93 ++++++++++++++++++++ src/2025h2/pub-priv.md | 74 ++++++++++++++++ 4 files changed, 432 insertions(+) create mode 100644 src/2025h2/cargo-plumbing.md create mode 100644 src/2025h2/cargo-script.md create mode 100644 src/2025h2/libtest-json.md create mode 100644 src/2025h2/pub-priv.md diff --git a/src/2025h2/cargo-plumbing.md b/src/2025h2/cargo-plumbing.md new file mode 100644 index 00000000..51df2823 --- /dev/null +++ b/src/2025h2/cargo-plumbing.md @@ -0,0 +1,159 @@ +# Prototype a new set of Cargo "plumbing" commands + +| Metadata | | +| :-- | :-- | +| Point of contact | @epage | +| Teams | | +| Task owners | | +| Status | Invited | +| Zulip channel | N/A | +| Tracking issue | [rust-lang/rust-project-goals#264] | + +## Summary + +Create a third-party cargo subcommand that has "plumbing" (programmatic) +subcommands for different phases of Cargo operations to experiment with what +Cargo should integrate. + +## Motivation + +Cargo is a "porcelain" (UX) focused command and is highly opinionated which can work well for common cases. +However, as Cargo scales into larger applications, users need the ability to adapt Cargo to their specific processes and needs. + +### The status quo + +While most Cargo commands can be used programmatically, they still only operate at the porcelain level. +Currently, Cargo's plumbing commands are +- `cargo read-manifest`: + - works off of a `Cargo.toml` file on disk + - uses a custom json schema + - deprecated +- `cargo locate-project`: + - works off of a `Cargo.toml` file on disk + - text or json output, undocumented json schema + - uses a pre-1.0 term for package +- `cargo metadata`: + - works off of `Cargo.toml`, `Cargo.lock` files on disk + - uses a custom json schema + - can include dependency resolution but excludes feature resolution + - some users want this faster + - some users want this to report more information + - See also [open issues](https://github.com/rust-lang/cargo/issues?q=is%3Aissue%20state%3Aopen%20label%3ACommand-metadata) +- `cargo pkgid`: + - works off of `Cargo.toml`, `Cargo.lock` files on disk + - text output +- `cargo verify-project`: + - works off of a `Cargo.toml` file on disk + - uses a custom json schema + - uses a pre-1.0 term for package + - deprecated + +There have been experiments for a plumbing for builds +- [`--build-plan`](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#build-plan) attempts to report what commands will be run so external build tools can manage them. + - The actual commands to be run is dynamic, based on the output of build scripts from build graph dependencies + - Difficulty in supporting build pipelining +- [`--unit-graph`](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#unit-graph) reports the graph the build operates off of which corresponds to calls to the compiler and build scripts + - Also provides a way to get the results of feature resolution + +### The next 6 months + +Create a third-party subcommand to experiment with plumbing commands. + +A build in Cargo can roughly be split into +1. Locate project +2. Read the manifests for a workspace +3. Read lockfile +4. Lock dependencies +5. Write lockfile +6. Resolve features +7. Plan a build, including reading manifests for transitive dependencies +8. Execute a build +9. Stage final artifacts + +These could serve as starting points for experimenting with plumbing commands. +Staging of final artifacts may not be worth having a dedicated command for. +This is exclusively focused on build while other operations may be of interest to users. +We can evaluate those commands in the future as they tend to still build off of these same core primitives. + +At minimum, later commands in the process would accept output from earlier commands, +allowing the caller to either replace commands (e.g. custom dependency resolver) +or customize the output (e.g. remove `dev-dependencies` from manifests). + +Encapsulating stabilized file formats can serve as a starting point for output +schemas as we already output those and have to deal with stability guarantees +around these. + +Between planning a build and executing a build is likely to look like +`--unit-graph` and a plan will need to be put forward for how to work through +the open issues. +There will likely be similar issues for any other output that can't leverage existing formats. + +Cargo's APIs may not be able to expose each of these stages and work may need to be done to adapt it to support these divisions. + +The performance of piping output between these commands may be sub-par, coming from a combination of at least +- Cargo's APIs may require doing more work than is needed for these stages +- Cargo focuses on json for programmatic output which may prove sub-par (see also [zulip](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/.60cargo.20metadata.60.20performance/near/476523460)) +- Cargo's serde structures may not be optimized +- If customizing only a single step in this process, + requiring serializing and deserializing through all of the other stages may be superfluous + +Low hanging or egregious bottlenecks may need to be addressed. +Otherwise, performance should wait on user feedback. + +A schema evolution plan will need to be considered with the design of the schema. +How Cargo deals with evolution of existing output could serve as potential starting points: +- `Cargo.toml` (generated by `cargo package`) should still be readable by `cargo` versions within the specified `package.rust-version` + - In the absence of a `package.rust-version`, `Cargo.toml` should only represent features the user explicitly used or optional features that were always allowed on stable `cargo` +- `Cargo.lock` (generated by most commands) is strictly versioned: all versions of Cargo should output a lockfile that works in all other versions of Cargo for that given version and changing Cargo versions should not cause the output to change + - Cargo bumps the default format version after it has been stabilized for a "sufficient period of time" + - The default is capped by what is supported by the lowest `package.rust-version` in the workspace +- `cargo metadata --format-version`: defaults to "latest" with a warning + - We attempt to follow the same practice as `Cargo.toml` +- `--message-format`: no versioning currently + - We attempt to follow the same practice as `Cargo.toml` + +### The "shiny future" we are working towards + +- Collect user feedback on these commands and iterate on them for eventual inclusion into Cargo +- Evaluate refactoring Cargo to better align with these plumbing commands to have better boundaries between subsystems +- Evaluate splitting the `cargo` `[lib]` into crates for each of these plumbing commands as smaller, more approachable, more "blessed" Rust APIs for users to call into + +## Design axioms + +- The changes to Cargo should not impede the development of Cargo +- The schemas and planned evolution should not impede the development of Cargo +- The plumbing commands should be focused on solving expected or known needs, avoiding speculation. + +## Ownership and team asks + +**Owner:** *Identify a specific person or small group of people if possible, else the group that will provide the owner. Github user names are commonly used to remove ambiguity.* + +*This section defines the specific work items that are planned and who is expected to do them. It should also include what will be needed from Rust teams. The table below shows some common sets of asks and work, but feel free to adjust it as needed. Every row in the table should either correspond to something done by a contributor or something asked of a team. For items done by a contributor, list the contributor, or ![Heap wanted][] if you don't yet know who will do it. For things asked of teams, list ![Team][] and the name of the team. The things typically asked of teams are defined in the [Definitions](#definitions) section below.* + +| Task | Owner(s) or team(s) | Notes | +|-----------------------------------------|--------------------------|-------| +| Discussion and moral support | ![Team][] [cargo] | | +| Implementation | ![Help wanted][] | | +| Optimizing Cargo | ![Help wanted][], @epage | | +| Inside Rust blog post inviting feedback | @epage | | + +### Definitions + +Definitions for terms used above: + +* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor. +* *Author RFC* and *Implementation* means actually writing the code, document, whatever. +* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected). +* *RFC decisions* means reviewing an RFC and deciding whether to accept. +* *Org decisions* means reaching a decision on an organizational or policy matter. +* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review. +* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize. +* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated. +* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting. +* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context. +* Other kinds of decisions: + * [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written. + * Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team. + * Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library. + +## Frequently asked questions diff --git a/src/2025h2/cargo-script.md b/src/2025h2/cargo-script.md new file mode 100644 index 00000000..3c3a57d6 --- /dev/null +++ b/src/2025h2/cargo-script.md @@ -0,0 +1,106 @@ +# Stabilize cargo-script + +| Metadata | | +|:-----------------|----------------------------------------------------------------------------------| +| Point of contact | @epage | +| Teams | | +| Task owners | | +| Status | Accepted | +| Tracking issue | [rust-lang/rust-project-goals#119] | +| Zulip channel | N/A (an existing stream can be re-used or new streams can be created on request) | + +## Summary + +Stabilize support for "cargo script", the ability to have a single file that contains both Rust code and a `Cargo.toml`. + +## Motivation + +Being able to have a Cargo package in a single file can reduce friction in development and communication, +improving bug reports, educational material, prototyping, and development of small utilities. + +### The status quo + +Today, at minimum a Cargo package is at least two files (`Cargo.toml` and either `main.rs` or `lib.rs`). +The `Cargo.toml` has several required fields. + +To share this in a bug report, people resort to +- Creating a repo and sharing it +- A shell script that cats out to multiple files +- Manually specifying each file +- Under-specifying the reproduction case (likely the most common due to being the eaisest) + +To create a utility, a developer will need to run `cargo new`, update the +`Cargo.toml` and `main.rs`, and decide on a strategy to run this (e.g. a shell +script in the path that calls `cargo run --manifest-path ...`). + +### The next 6 months + +The support is already implemented on nightly. +The goal is to stabilize support. +With [RFC #3502] and [RFC #3503] approved, the next steps are being tracked in [rust-lang/cargo#12207]. + +At a high-level, this is +- Add support to the compiler for the frontmatter syntax +- Add support in Cargo for scripts as a "source" +- Polish + +### The "shiny future" we are working towards + +## Design axioms + +- In the trivial case, there should be no boilerplate. The boilerplate should scale with the application's complexity. +- A script with a couple of dependencies should feel pleasant to develop without copy/pasting or scaffolding generators. +- We don't need to support everything that exists today because we have multi-file packages. + +## Ownership and team asks + +Tracking issue [cargo#12207](https://github.com/rust-lang/cargo/issues/12207): + +| Task | Owner(s) or team(s) | Notes | +|------------------------------|---------------------|-------| +| Discussion and moral support | ![Team][] [cargo], [compiler] | | +| Ensure Cargo implementation | @epage | | + +### Implement language feature `frontmatter` + +Tracking issue [#136889](https://github.com/rust-lang/rust/issues/136889): + +| Task | Owner(s) or team(s) | Notes | +|-----------------------------------|------------------------------------|-------| +| Rustc implementation | @epage | | +| Rust-analyzer implementation | @epage | | +| Standard reviews | ![Team][] [compiler] | | +| Lang-team champion | ![Team][] [lang] | @joshtriplett | +| Author call for testing blog post | @epage | | + +### Stabilize language feature `frontmatter` + +| Task | Owner(s) or team(s) | Notes | +|--------------------------------|------------------------------------|-------| +| Author specification 1st draft | @epage | | +| Finalize specification text | ![Team][] [spec] | @ehuss | +| Lang-team champion | ![Team][] [lang] | @joshtriplett | +| Author stabilization report | @epage | | +| Author stabilization PR | @epage | | +| Stabilization decision | ![Team][] [lang] | | + +### Definitions + +For definitions for terms used above, see the [About > Team Asks](https://rust-lang.github.io/rust-project-goals/about/team_asks.html) page. + +* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor. +* *Author RFC* and *Implementation* means actually writing the code, document, whatever. +* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected). +* *RFC decisions* means reviewing an RFC and deciding whether to accept. +* *Org decisions* means reaching a decision on an organizational or policy matter. +* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review. +* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize. +* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated. +* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting. +* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context. +* Other kinds of decisions: + * [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written. + * Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team. + * Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library. + +## Frequently asked questions diff --git a/src/2025h2/libtest-json.md b/src/2025h2/libtest-json.md new file mode 100644 index 00000000..f9fa6f2e --- /dev/null +++ b/src/2025h2/libtest-json.md @@ -0,0 +1,93 @@ +# Finish the libtest json output experiment + +| Metadata | | +| :-- | :-- | +| Point of contact | @epage | +| Teams | | +| Task owners | | +| Status | Accepted | +| Zulip channel | N/A | +| Tracking issue | [rust-lang/rust-project-goals#255] | + +## Summary + +Finish the [libtest json experiment](https://rust-lang.github.io/rfcs/3558-libtest-json.html). + +## Motivation + +[libtest](https://github.com/rust-lang/rust/tree/master/library/test) +is the test harness used by default for tests in cargo projects. +It provides the CLI that cargo calls into and enumerates and runs the tests discovered in that binary. +It ships with rustup and has the same compatibility guarantees as the standard library. + +Before 1.70, anyone could pass `--format json` despite it being unstable. +When this was fixed to require nightly, +this helped show [how much people have come to rely on programmatic output](https://www.reddit.com/r/rust/comments/13xqhbm/announcing_rust_1700/jmji422/). + +Cargo could also benefit from programmatic test output to improve user interactions, including +- [Wanting to run test binaries in parallel](https://github.com/rust-lang/cargo/issues/5609), like `cargo nextest` +- [Lack of summary across all binaries](https://github.com/rust-lang/cargo/issues/4324) +- [Noisy test output](https://github.com/rust-lang/cargo/issues/2832) (see also [#5089](https://github.com/rust-lang/cargo/issues/5089)) +- [Confusing command-line interactions](https://github.com/rust-lang/cargo/issues/1983) (see also [#8903](https://github.com/rust-lang/cargo/issues/8903), [#10392](https://github.com/rust-lang/cargo/issues/10392)) +- [Poor messaging when a filter doesn't match](https://github.com/rust-lang/cargo/issues/6151) +- [Smarter test execution order](https://github.com/rust-lang/cargo/issues/6266) (see also [#8685](https://github.com/rust-lang/cargo/issues/8685), [#10673](https://github.com/rust-lang/cargo/issues/10673)) +- [JUnit output is incorrect when running multiple test binaries](https://github.com/rust-lang/rust/issues/85563) +- [Lack of failure when test binaries exit unexpectedly](https://github.com/rust-lang/rust/issues/87323) + +Most of that involves shifting responsibilities from the test harness to the test runner which has the side effects of: +- Allowing more powerful experiments with custom test runners (e.g. [`cargo nextest`](https://crates.io/crates/cargo-nextest)) as they'll have more information to operate on +- Lowering the barrier for custom test harnesses (like [`libtest-mimic`](https://crates.io/crates/libtest-mimic)) as UI responsibilities are shifted to the test runner (`cargo test`) + +### The status quo + +### The next 6 months + +1. Experiment with potential test harness features +2. Experiment with test reporting moving to Cargo +3. Putting forward a proposal for approval + +### The "shiny future" we are working towards + +- Reporting shifts from test harnesses to Cargo +- We run test harnesses in parallel + +## Design axioms + +- Low complexity for third-party test harnesses so its feasible to implement them +- Low compile-time overhead for third-party test harnesses so users are willing to take the compile-time hit to use them +- Format can meet expected future needs + - Expected is determined by looking at what other test harnesses can do (e.g. fixture, paramertized tests) +- Format can evolve with unexpected needs +- Cargo perform all reporting for tests and benches + +## Ownership and team asks + +*This section defines the specific work items that are planned and who is expected to do them. It should also include what will be needed from Rust teams. The table below shows some common sets of asks and work, but feel free to adjust it as needed. Every row in the table should either correspond to something done by a contributor or something asked of a team. For items done by a contributor, list the contributor, or ![Heap wanted][] if you don't yet know who will do it. For things asked of teams, list ![Team][] and the name of the team. The things typically asked of teams are defined in the [Definitions](#definitions) section below.* + +| Task | Owner(s) or team(s) | Notes | +|-----------------------------------|---------------------------|-------| +| Discussion and moral support | ![Team][] [testing-devex], [cargo], [libs-api] | | +| Prototype harness | @epage | | +| Prototype Cargo reporting support | @epage | | +| Write stabilization report | @epage | | + +### Definitions + +Definitions for terms used above: + +* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor. +* *Author RFC* and *Implementation* means actually writing the code, document, whatever. +* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected). +* *RFC decisions* means reviewing an RFC and deciding whether to accept. +* *Org decisions* means reaching a decision on an organizational or policy matter. +* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review. +* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize. +* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated. +* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting. +* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context. +* Other kinds of decisions: + * [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written. + * Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team. + * Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library. + +## Frequently asked questions \ No newline at end of file diff --git a/src/2025h2/pub-priv.md b/src/2025h2/pub-priv.md new file mode 100644 index 00000000..de858cc4 --- /dev/null +++ b/src/2025h2/pub-priv.md @@ -0,0 +1,74 @@ +# Stabilize public/private dependencies + +| Metadata | | +| :-- | :-- | +| Point of contact | @epage | +| Teams | | +| Task owners | | +| Status | Invited | +| Zulip channel | N/A | +| Tracking issue | [rust-lang/rust-project-goals#272] | + +## Summary + +Find a MVP for stabilization and move it forward. + +## Motivation + +This will allow users to tell Rustc and Cargo what dependencies are private +- Help users catch ways they unexpectedly expose their implementation details +- Help tooling better identify what all consistutes an API + +### The status quo + +[RFC #1977](https://github.com/rust-lang/rfcs/pull/1977) has been superseded by +[RFC #3516](https://github.com/rust-lang/rfcs/pull/3516) to reduce complexity on the Cargo side to help get this over the line. +However, there is still a lot of complexity on the compiler side to get this right +( +[rust#3516](https://github.com/rust-lang/rfcs/pull/3516), +[rust#119428](https://github.com/rust-lang/rust/issues/119428), +), +keeping this feature in limbo + +### The next 6 months + +Work with [compiler] to identify a minimal subset of functionality for what the lint can do and close out the remaining stabilization tasks. + +### The "shiny future" we are working towards + +## Design axioms + +- False negatives are likely better than false positives + +## Ownership and team asks + +*This section defines the specific work items that are planned and who is expected to do them. It should also include what will be needed from Rust teams. The table below shows some common sets of asks and work, but feel free to adjust it as needed. Every row in the table should either correspond to something done by a contributor or something asked of a team. For items done by a contributor, list the contributor, or ![Heap wanted][] if you don't yet know who will do it. For things asked of teams, list ![Team][] and the name of the team. The things typically asked of teams are defined in the [Definitions](#definitions) section below.* + +| Task | Owner(s) or team(s) | Notes | +|------------------------------|-------------------------------|-------| +| Discussion and moral support | ![Team][] [cargo], [compiler] | | +| Work through #3516, #119428 | ![Help wanted][] | | +| Finish any remaining tasks | ![Help wanted][] | | +| Mentoring | @epage | | +| Stabilization report | ![Help wanted][] | | + +### Definitions + +Definitions for terms used above: + +* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor. +* *Author RFC* and *Implementation* means actually writing the code, document, whatever. +* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected). +* *RFC decisions* means reviewing an RFC and deciding whether to accept. +* *Org decisions* means reaching a decision on an organizational or policy matter. +* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review. +* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize. +* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated. +* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting. +* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context. +* Other kinds of decisions: + * [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written. + * Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team. + * Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library. + +## Frequently asked questions \ No newline at end of file From 2ccce27444b2259d509c86f221540dc8aebec674 Mon Sep 17 00:00:00 2001 From: Ed Page Date: Thu, 19 Jun 2025 15:19:10 -0500 Subject: [PATCH 2/2] Update project goals from 2025h1 --- src/2025h2/cargo-plumbing.md | 2 +- src/2025h2/cargo-script.md | 15 ++++++++------- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/src/2025h2/cargo-plumbing.md b/src/2025h2/cargo-plumbing.md index 51df2823..95b8bbf2 100644 --- a/src/2025h2/cargo-plumbing.md +++ b/src/2025h2/cargo-plumbing.md @@ -57,7 +57,7 @@ There have been experiments for a plumbing for builds ### The next 6 months -Create a third-party subcommand to experiment with plumbing commands. +Continue on the third-party subcommand to experiment with plumbing commands ([source](https://github.com/crate-ci/cargo-plumbing)). A build in Cargo can roughly be split into 1. Locate project diff --git a/src/2025h2/cargo-script.md b/src/2025h2/cargo-script.md index 3c3a57d6..9101fcf3 100644 --- a/src/2025h2/cargo-script.md +++ b/src/2025h2/cargo-script.md @@ -35,14 +35,15 @@ script in the path that calls `cargo run --manifest-path ...`). ### The next 6 months -The support is already implemented on nightly. -The goal is to stabilize support. -With [RFC #3502] and [RFC #3503] approved, the next steps are being tracked in [rust-lang/cargo#12207]. +Cargo and basic rustc support is already implemented on nightly. +The goal is to finalize things within the rust repo and stabilize. +With [RFC #3502] and [RFC #3503] approved, the next steps are being tracked in [rust-lang/cargo#12207] and [rust-lang/rust#136889](https://github.com/rust-lang/rust/issues/136889). At a high-level, this is -- Add support to the compiler for the frontmatter syntax -- Add support in Cargo for scripts as a "source" -- Polish +- rustfmt gracefully handling the presence of a frontmatter +- r-a gracefully handling the presence of a frontmatter +- Fix a known bug in rustc's lexer ([rust-lang/rust#141367](https://github.com/rust-lang/rust/issues/141367)). +- Improve error messages in Cargo ### The "shiny future" we are working towards @@ -67,8 +68,8 @@ Tracking issue [#136889](https://github.com/rust-lang/rust/issues/136889): | Task | Owner(s) or team(s) | Notes | |-----------------------------------|------------------------------------|-------| -| Rustc implementation | @epage | | | Rust-analyzer implementation | @epage | | +| rustfmt implementation | @epage | | | Standard reviews | ![Team][] [compiler] | | | Lang-team champion | ![Team][] [lang] | @joshtriplett | | Author call for testing blog post | @epage | |