Comment by @tmandry posted on 2025-05-20:

Async fn in traits. An FCP proposal to stabilize return type notation was started in https://github.com/rust-lang/rust/pull/138424. However, it is currently blocked on concerns that stabilizing it now will make it more difficult to ship Rust's next-generation trait solver.

Async fn in dyn trait. There have been discussions around next steps to support this in the language. More experimentation is needed, along with an initial RFC.

dynosaur. More breaking changes have landed and we expect to release v0.3 soon.

Comment by @m-ou-se posted on 2025-04-23:

Update:

Below is the preliminary schedule for the "pre all hands" and all hands:

The last day has a lot of empty slots for now. I'm still working on filling those, but I'll leave a few empty slots to allow for flexibility during the event itself.

Comment by @m-ou-se posted on 2025-04-23:

I published our covid policy: https://rustweek.org/covid-policy-all-hands-and-unconf/

And got us a ton of covid self-tests and Aranet4 CO₂ sensors:

Comment by @m-ou-se posted on 2025-04-23:

For remote attendance, I got us a bunch of Jabra Speak2 75 conferencing speaker-microphones. They are battery powered and work out-of-the-box both over USB and Bluetooth on any platform.

I'll put them near the entrance for anyone to borrow for any of the meeting rooms.

Comment by @ojeda posted on 2025-05-20:

Update from our 2025-04-09 meeting (full minutes):

• Some progress on arbitrary_self_types. In particular, decided to do with respect to pin and other related cases.

• asm_goto is solved, apart from output operands. For asm_const, https://github.com/rust-lang/rust/pull/138618 is nominated.

• ABI-modifying compiler flags: some PRs waiting review, e.g. https://github.com/rust-lang/rust/pull/138736.

• --crate-attr RFC is up: https://github.com/rust-lang/rfcs/pull/3791.

• -Zsanitize-kcfi-arity's implementation PR got merged: https://github.com/rust-lang/rust/pull/138368. If all is good from the Linux side, a stabilization PR will be sent.

• CFI core::fmt issue: https://github.com/rust-lang/rust/issues/115199.

• Discussion around bindgen, repr(align) and packed types. RFC nominated for lang discussion: https://github.com/rust-lang/rfcs/pull/3718#issuecomment-2790654254.

Comment by @ojeda posted on 2025-05-20:

Update from our 2025-04-23 meeting (full minutes):

• Naked functions were stabilized, which could see some use in the kernel.

• Lang discussed #[repr(align)] (the kernel is interested in, at least, the global one, i.e. -Zmin-function-alignment=N).

• asm_const: @nbdd0121 will reply on the latest review comments in the implementation PR: https://github.com/rust-lang/rust/issues/128464.

• --crate-attr: the author of the RFC (https://github.com/rust-lang/rfcs/pull/3791) is looking for a new owner. The RFC is in proposed FCP. Small updates to the text may be needed. Otherwise compiler probably wants to merge it. @Mark-Simulacrum to be pinged.

• Clippy configuration etc.: @flip1995 will be at RustWeek, the plan is to discuss it there.

• rustdoc extract doctests: @GuillaumeGomez and @ojeda plan to discuss it at RustWeek.

• -Zsanitize-kcfi-arity: waiting on the kernel side (tc-build support sent).

• CFI core::fmt issue: PR submitted: https://github.com/rust-lang/rust/pull/139632.

Comment by @BoxyUwU posted on 2025-04-30:

I've a PR open to make resolving inherent assoc terms in item signatures not result in query cycles, this will be necessary for uses of inherent assoc consts in the type system under mgca. camelid is currently working on representing const items as aliases to type system consts rather than bodies like they currently are, this is necessary to implement normalization of const const aliases under mgca, it will also allow us to implement the core mgca check of const aliases in the type system being equal to valid const arguments, and also we'll be able to split out a full gca feature gate without that restriction.

The PR mentioned in the previous update to handle const aliases with inference variables correctly has turned into a bit of a rabbit hole. It turned out that there were stable issues around const evaluation and illformed constants resulting in ICEs so I've wound up trying to get those fixed and have been writing up a document explaining justification for a breaking change there.

Comment by @davidtwco posted on 2025-05-07:

• We've started a regular biweekly sync call with upstream stakeholders in build-std from the lang, compiler and cargo teams where we discuss aspects of our tentative design or clarify constraints.
• @adamgemmell has continued to draft our proposal for build-std, which we're discussing in our regular sync calls.
• We're hosting a session at the All Hands next week to discuss build-std.

Comment by @obi1kenobi posted on 2025-05-03:

We encountered some speedbumps this month.

TL;DR:

• While working on 'static and "outlives" bounds, we discovered Rust's ability to imply bounds that are not stated explicitly at the definition site.
• Implied bounds are load-bearing for SemVer; failure to take them into account will produce both false-positives and false-negatives.
• While technical limitations make it infeasible for cargo-semver-checks to correctly deduce implied bounds, rustc has this capability internally.
• We have asked the rustdoc team to expose implied bounds in rustdoc JSON by using those rustc internal APIs.

There are some good news as well, though! While looking at the #[target_feature] attribute:

• We discovered previously-undocumented SemVer hazards.
• We discovered a case of unsoundness when that attribute is used on trait methods.
• With the help of contributors and the rustdoc team, rustdoc JSON began including additional information that will help future cargo-semver-checks versions catch those SemVer hazards.

Comment by @nikomatsakis posted on 2025-04-08:

In reviewing https://github.com/rust-lang/rust/pull/138628, we realized that the tests were not behaving as expected because they were running in Rust 2015 which had distinct capture rules. My suggestion was to limit the use keyword (or at least use closures...) to Rust 2021 so as to avoid having to think about how it interacts with earlier capture rules (as well as potential migrations). I believe this follows from the Edition axiom that Editions are meant to be adopted.

There is an interesting tension with Rust should feel like one language. My feeling is that there is a missing tenet: the reason we do editions and not fine-grained features is because we wish to avoid combianotoric explosion, where odd combinations of features can lead to untested scenarios. But that is exactly what would be happening here if we allow use on older editions. So I think the rule should be that you make new features available on older editions up until the point where they interact with something that changed -- in this case, use closures interact with the closure capture rules which changed in Rust 2021, so we should limit this feature to Rust 2021 and newer.

Put another way, you should never have to go back and modify an edition migration to work differently. That suggestions you are attempting to push the feature too far back.

Comment by @spastorino posted on 2025-04-30:

We've modified codegen so that we guarantee that x.use will do a copy if X: Copy is true after monomorphization. Before this change the desugaring to clone occurred only before monomorphization and hence it would call the clone method even for those instances where X is a Copy type. So with this modification we avoid such situation.

We are not working on convert x.use to a move rather than a clone if this is a last-use.

Comment by @Eh2406 posted on 2025-05-03:

I will be giving a talk at Rust-Week about the history that brought us to this project/goal. Aside from preparing for that talk I have not had time for this effort.

Comment by @epage posted on 2025-04-30:

• Key developments:
  • Continued efforts to clean up the existing code
  • t-testing-devex has been working out where the crates should live in preparation for publishing them (#t-testing-devex > crate ownership @ 💬)
  • Looking to build on the work done for test-r and rustest crates as they align with the long term vision
• Blockers:
• Help wanted:

Comment by @eholk posted on 2025-04-30:

@b-naber and I have been working on the rustc side of the implementation for this feature.

I merged https://github.com/rust-lang/rust/pull/139647, which adds the unstables -Z namespaced-crates option to the compiler and enables parsing of externs like --extern foo::bar=libbar.rlib. @b-naber has led the resolver changes and has a draft PR up at https://github.com/rust-lang/rust/pull/140271.

The implementation work has raised some new concerns about the overall direction, so work is ongoing to resolve those while continuing to make progress in the meantime.

Comment by @celinval posted on 2025-04-30:

We fixed issue https://github.com/rust-lang/rust/issues/136925 that was blocking contract annotations on constant functions, which unblocks the initial PR to add some contract annotations in the standard library (https://github.com/rust-lang/rust/pull/136578). The PR currently triggers a CI failure which we are investigating.

Comment by @jieyouxu posted on 2025-05-01:

Update (2025-05-01):

• Not much updates, recent compiletest changes were surrounding error annotation strictness/canonicalization and landing a new executor that doesn't depend on libtest, and I've mostly been involved in reviewing those.
• Next planned changes are first to introduce some discipline into compiletest's error handling and contributor-facing diagnostics, because configuration and directive handling currently still has a ton of random panics all over the place.

Comment by @yaahc posted on 2025-04-16:

Small progress update:

following the plan mentioned above plus some extra bits, I've implemented the following changes

• changed the json output to include the timestamp
• changed the file naming to ensure uniqueness and not overwrite metrics for the same crate when built with different configurations
  • previously I was piggybacking on the hash used to name artifacts in the .cargo or build directories, which in the compiler is known as extra_filename and is configured by cargo, but it turns out this doesn't guarantee uniqueness
  • I've replaced this with the "Strict Version Hash" (SVH)
    • Doing so introduced an ICE when compiling some crates with incremental compilation enabled. I've since resolved this in https://github.com/rust-lang/rust/pull/139502 and tested this version against the top 100 crates in the ecosystem and their dependencies to verify its working
• I've been working with the infra team and they've setup a cloud instance of influxdb 3.0 and grafana, influxdb is setup, grafana in progress
• I met with both libs and lang to discuss their needs related to the unstable feature usage metrics and metrics in general

Next Steps:

• I've got everything setup for the docs.rs team to start gathering a sample dataset for which I will then upload to the server the infra team setup
• update locally hosted PoC impl to work with recent changes to metrics files and naming and validate that it's working as expected
• work on the queries for the grafana instance to setup a graph per feature showing usage over time
  • probably going to create fake usage data to with for this
• on the side I'm also looking into how much work it would be to track relative usage of various library APIs under a single feature flag (e.g. https://github.com/rust-lang/rust/issues/139911 tracking the specific functions used)
• develop a better understanding of the expected cost of running an influxdb server

Comment by @yaahc posted on 2025-04-22:

posting this here so I can link to it in other places, I've setup the basic usage over time chart using some synthesized data that just emulates quadraticly (is that a word?) increasing feature usage for my given feature over the course of a week (the generated data starts at 0 usages per day and ends at 1000 usages per day). This chart counts the usage over each day long period and charts those counts over a week. The dip at the end is the difference between when I generated the data, after which there is zero usage data, and when I queried it.

With this I should be ready to just upload the data once we've gathered it from docs.rs, all I need to do is polish and export the dashboards I've made from grafana to the rust-lang grafana instance, connect that instance to the rust-lang influxdb instance, and upload the data to influxdb once we've gathered it.

Comment by @lcnr posted on 2025-05-01:

We've made a lot of progress over the last 1.5 months. My change to opaque types in borrowck is pretty much done now: https://github.com/rust-lang/rust/pull/139587. It still needs some cleanup and an FCP to actually merge. We've already merged multiple cleanups on the way here.

We then started to test crater with the -Znext-solver=globally. @compiler-errors and me encountered and merged the fixes for 13 issues since then: https://github.com/rust-lang/rust/pull/139791 https://github.com/rust-lang/rust/pull/139798 https://github.com/rust-lang/rust/pull/140236 https://github.com/rust-lang/rust/pull/139900 https://github.com/rust-lang/rust/pull/139828 https://github.com/rust-lang/rust/pull/139774 https://github.com/rust-lang/rust/pull/139762 https://github.com/rust-lang/rust/pull/139789 https://github.com/rust-lang/rust/pull/138845 https://github.com/rust-lang/rust/pull/140306 https://github.com/rust-lang/rust/pull/140305 <https://github.com/rust-lang/rust/pull/140276 https://github.com/rust-lang/rust/pull/140302. @Nadrieril was also helpful by minimizing an encountered issue.

With these improvements and multiple in-flight changes we're now at significantly less than 100 remaining regressions in the top 10000 crates and have started the first complete crater run today. We are using a single PR for all crater runs. Check out https://github.com/rust-lang/rust/pull/133502 for the current status and the stack of in-flight changes.

Comment by @veluca93 posted on 2025-04-30:

Key developments: nothing substantial.

Comment by @blyxyas posted on 2025-04-29:

Monthly update!

• In the last monthly update we saw the impact that interning symbols had on the program's performance. An effort to minimize this via a pre-interning symbol mechanism has been implemented in https://github.com/rust-lang/rust-clippy/pull/14650 and https://github.com/rust-lang/rust/pull/138682

• We're phasing out the old "str path" infrastructure into a new lazy alternative. https://github.com/rust-lang/rust-clippy/pull/14705

• We're currently in the effort to optimize some documentation lints that took up to 15% of the Clippy runtime (depending on how much documentation for each line of code you had.) See https://github.com/rust-lang/rust-clippy/pull/14693

• We've also been experimenting with lots of new possibilities, mainly on parallel lints. Although they currently are not performance improvements, there are some great hope put into them.

• Memory consumption and branch mispredictions are being monitored, they do not seem out of the ordinary.

• Monitoring cache misses and references, turns out that about 31% of cache references (792m found) are cache misses (253m found) in some benchmarks. We will check what's behind those numbers and if they can be improved.

This has been a great month for performance!

Comment by @oli-obk posted on 2025-04-30:

No updates

Comment by @epage posted on 2025-04-30:

• Key developments:
  • The cargo-plumbing repo was created to serve as the central place for collaboration on this effort
  • @ashiskumarnaik posted crate-ci/cargo-plumbing#5 for the first plumbing command
• Blockers:
• Help wanted:

Comment by @ojuschugh1 posted on 2025-05-05:

Hi @epage , I am interested in working on this project. If you are still looking for someone.

Comment by @epage posted on 2025-05-05:

@ojuschugh1 iirc there is a GSoC proposal for this and we are waiting to hear whether it was accepted. If it was, it would likely involve coordinating with them on tasks.

Comment by @JoelMarcey posted on 2025-05-02:

Key Developments: The FLS repo has officially been transferred from Ferrous to the Rust Project. https://github.com/rust-lang/fls is now live.

Next step: Integrate the FLS with the Rust build system in order to support publishing within project processes.

Blockers: None yet. The build system integration could create some support requests, however.

Comment by @celinval posted on 2025-04-30:

We have started the refactoring. @makai410 has moved all the existing code into a single crate and they have started moving things around.

Comment by @davidtwco posted on 2025-05-07:

• @Jamesbarford has been working with @Kobzol to implement a database-backed job queueing mechanism, which will better scale to support multiple collectors and ends up being the key part of rustc-perf needing adapted to support multiple collectors.
• @Jamesbarford has also upstreamed tests for the existing queue ordering (rust-lang/rustc-perf#2072).

Comment by @lqd posted on 2025-05-05:

Here are the key developments for the month of April

• @amandasystems
  • extracted a handful of PRs out of the gigantic placeholder rewrite PR, to make it easier to review and land
  • https://github.com/rust-lang/rust/pull/139960, https://github.com/rust-lang/rust/pull/139965, and https://github.com/rust-lang/rust/pull/140466
• Tage
  • continued experimenting and making progress with the early phase of the process, and making building constraints, and traversing them per loan, lazy
  • started extracting some of that work for discussion, review, PRs, as well as writing reports for his masters thesis
• @lqd
  • continued on improving the algorithm. We're now at a point where we have an approximation of the datalog algorithm, which handles our UI tests -- except one where control flow in a loop connects to regions that are live before and after the loop: this causes a false positive that our datalog implementation used to accept (via a more comprehensive but slower approach).
  • we're currently discussing whether we can cut scope here, as this formulation accepts NLL problem case 3. We'll need to evaluate what limits this formulation imposes on expressiveness outside NLL problem case 3 and streaming iterators -- and whether it indeed has an easier path to becoming production ready. We'll also still try to see if it's possible to still improve the algorithm and avoid emitting errors on issue 46589, since we initially hoped to fix this one as well.

Comment by @epage posted on 2025-04-30:

Key developments:

• @fee1-dead posted rust-lang/rust#140035 for compiler support for frontmatters (which supersedes rust-lang/rust#137193)

Blockers:

Help wanted:

Comment by @davidtwco posted on 2025-05-07:

• We've resolved a handful of rounds of feedback on rust-lang/rust#137944 from @oli-obk, @lcnr and @fee1-dead; resolved issues from a crater run (bar one); and worked to decrease the performance regression.
  • We've removed the constness parts of the patch to make it smaller and easier to review. Constness will come in a Part II.
  • There's currently a -1% mean regression (min 0.1%, max 5.3%) that we're working to improve, but starting to run out of ideas. Regressions are just a consequence of the compiler having to prove more things with the addition of MetaSized bounds, rather than hot spots in newly introduced code.
  • Given the large impact of the change, we ran a crater run and found three distinct issues, two have been fixed. The remaining issue is a overflow in a single niche crate which we're working out how we can resolve.
  • We're largely just waiting on hearing from our reviewers what would be needed to see this change land.
• We've not made any changes to the Sized Hierarchy RFC, there's a small amount of discussion which will be responded to once the implementation has landed.
• We're working on changes to the SVE RFC which further clarifies that the language changes are decided by the Sized RFC and that the SVE RFC is only proposing the forever-unstable repr(scalable) attribute which are non-const Sized and lower to vscale in LLVM.

Comment by @jswrenn posted on 2025-04-18:

Key developments: After the last lang team meeting, Ralf observed that the additive/subtractive dichotomy (and its attendant design concerns w.r.t. Drop) could be sidestepped, since a field type already cannot be put into an unsound-to-drop state without unsafe code. With this observation, we can reduce field safety tooling to two rules:

1. a field should be marked unsafe if it carries a safety invariant (of any kind)
2. a field marked unsafe is unsafe to use

The RFC now reflects this design and has more or less reached a fixed point. Ongoing discussion on the RFC is now mostly limited to weighing this design against a proposed alternative that mixes syntactically knobs and wrapper types. The RFC would benefit from formal review by @rust-lang/lang.