Stabilize the next-generation trait solver

@lcnr

Metadata
Contact	@lcnr
Team(s)	lang (@nikomatsakis), types (@lcnr)
Goal document	2026/next-solver
Funding contact	Hexcat

Summary

Stabilize -Znext-solver=globally, replacing the existing trait solver implementation entirely.

This issue is intended for status updates only.

For general questions or comments, please contact a goal owner or post in the Zulip topic.

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

@compiler-errors

I am currently working on caching in the trait solver. The current implementation results in hangs when encountering complex auto-trait cycles. See https://rust-lang.zulipchat.com/#narrow/stream/364551-t-types.2Ftrait-system-refactor/topic/Fuchsia.20hanging.20on.20.60-Znext-solver.3Dcoherence.60 for the progress here. We now have an approach which fixes the performance regression. It'll still take at least multiple weeks until it's ready for merge however.

The librarification of the trait solver is in a very good state thanks to a lot of work by @compiler-errors. We're currently discussing its use in r-a on zulip: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/New.20Trait.20Solver. While there are still components we intend to move from rustc into the shared library to enable their reuse, all major ones have already been moved by now.

Since the last update, we've landed the new caching optimization in rust-lang/rust#128828 and hope to land the -Znext-solver=coherence stabilization PR this week.

There has been one other bug fix in the last month, see https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Amerged+label%3AWG-trait-system-refactor+-label%3Arollup+closed%3A%3C2024-09-02+-closed%3A%3C2024-08-01 for the full list of PRs.

We've tried to stabilize -Znext-solver=coherence in rust-lang/rust#121848 which we had to revert later (rust-lang/rust#130249) as it caused a hang in nalgebra.

We mostly fixed this hang with rust-lang/rust#130617 and rust-lang/rust#130821. As nalgebra still ends up hitting the recursion limit with a quite wide search graph, the performance impact of enabling -Znext-solver=coherence is quite bad rust-lang/rust#130654 (comment).

There haven't been any other significant changes to the new solver during the last month.

We stabilized -Znext-solver=coherence again in rust-lang/rust#130654. It's looking like the stabilization will actually go through this time.

We're currently refactoring the way the current "typing mode" is tracked, cc rust-lang/types-team#128. This is necessary to fix rust-lang/trait-system-refactor-initiative#106. I also started an FCP to clean up the way we merge candidates when proving trait goals: rust-lang/rust#132325. I intend to pretty much exactly match this behavior in the new solver as well, so I expect all of our issues there to be resolved.

@compiler-errors

The -Znext-solver=coherence stabilization didn't encounter any issues and is now on beta. Published a new update blogpost. We've made significant progress on bootstrap with -Znext-solver=globally this last month. I finished the core of the "typing mode" refactor with rust-lang/rust#133242 which then allowed me to unblock bootstrap via rust-lang/rust#133501. There has been a lot of work by @compiler-errors and myself with significant help from @lqd since then.

We're now able to bootstrap using exclusively the new solver. This allowed us to finish the first @bors try-run and run the benchmark suite for the first time. There are 3 remaining benchmarks which fail to compile and quite a few with very significant performance regressions. I am now working towards proper support for defining uses of opaque types inside of closures to fix wg-grammar.

This is a continuing project goal, and the updates below this comment will be for the new period 2025h1

@adwinwhite

The last 3 weeks saw us finish the behavior changes of the normalization rework. We merged the initial PR by @adwinwhite adding rigid aliases in rust-lang/rust#156742 and then landed rust-lang/rust#156976 by @lcnr and rust-lang/rust#158643 by @adwinwhite as followup. With this @khyperia was able to do an internal cleanup removing AliasRelate predicates in rust-lang/rust#158606. There's a bunch of in progress cleanup work after these changes in which is tracked in rust-lang/rust#155345.

There was also a bunch of smaller improvements. @ChayimFriedman2 merged an improvement to impl lookup for RustAnalyzer in rust-lang/rust#156295. @ShoyuVanilla continued their improvements to the way Projection goals are handled in rust-lang/rust#157718 and rust-lang/rust#158705. They also fixed a minor diagnostics bug in #158536. @jdonszelmann worked on a small improvement in rust-lang/rust#158355. @adwinwhite fixed an opaque type issue in rust-lang/rust#158478 and did some minor cleanp work in rust-lang/rust#158951 and rust-lang/rust#159050. @Jamesbarford fixed a rustdoc ICE with the new solver in rust-lang/rust#158346.

We currently have a few more in process behavior changes. Notably @ShoyuVanilla is working on a fix for rust-lang/trait-system-refactor-initiative#248, @adwinwhite is working on a PR to lower errors due to improvements to the way we track the recursion depth in the trait solver to FCW, and @jdonszelmann is continuing to work on performance improvements for the new trait solver.

Even without these changes, we're now in a really good spot and started another crater run with the new solver in rust-lang/rust#133502 and intend to enable the new solver by default on nightly for testing in a few weeks. Depending on whether that surfaces any new major issues, the new trait solver should be ready for stabilization in 2-3 months.

@lqd

We are currently preparing to enable the new solver by default and the corresponding compiler MCP (rust-lang/compiler-team#1014) is currently in FCP.

There's still a bit crater and performance triage we need to do, and then it's time to write an announcement blog post and actually enable it by default in a few weeks.

@lqd has compared the performance of the old and the new solver for the top 10000 crates on crates.io: zulip. The median and average are both below a 10% performance regression.

There were already 150 crates where the new solver is more than 10% faster. For the projection-caching stress test the new solver is currently 5x faster than the old one.

There are still still a few outliers worth looking into here and also just a lot of space for micro optimizations with the new solver. I am feeling very good about the current performance results. If you want to help out here, join us on zulip.

The crater run in rust-lang/rust#133502 uncovered three new minor bugs in the new solver which have already been fixed by @adwinwhite in rust-lang/rust#158993, rust-lang/rust#159460, and rust-lang/rust#159646.

This crater run currently uses a doubled recursion depth. @adwinwhite has been working on changing this to a FCW instead. This work is now pretty much done, see rust-lang/rust#159224.

Since the last crater run, a new version of tera has been released which breaks with the new solver. I opened a fix in Keats/tera#1001 after which @Keats very quickly published a new version. Thank you!

There's currently a lot of ongoing cleanup work related to the new solver, the normalization refactor (rust-lang/rust#155345) and the type system librarification (rust-lang/rust#159654). If you want to get involved, see this zulip stream.

@ShoyuVanilla is currently working on fix for rust-lang/trait-system-refactor-initiative#248. While this does not strictly block the stabilization of the new solver, it is desirable to minimize the negative impact of stabilizing the new solver as much as possible. @jdonszelmann continues to look into next-solver performance, currently experimenting with different ways to optimize ParamEnv handling.

rust-lang/rust#158731 by @adwinwhite is a significant internal cleanup while also improving perf by up to 5%. Both @bit-aloo and @Jamesbarford have been contributing to the cleanup work with rust-lang/rust#158668 and rust-lang/rust#154989 respectively. @Dnreikronos rust-lang/rust#159194 fixed an ICE in rustdoc.

@adwinwhite

It is kind of wild how many things happen here every week. I am currently writing a blogpost explaining the path towards stabilization and discussed what to do here in the Types Team meeting this week. I intend to publish this blogpost next week.

There is currently a lot going on in parallel and there are also open calls for participation on zulip. The first full crater run without any pending changes finished this morning and we're currently triaging its results.

The last large change to the new trait solver was rust-lang/rust#159224, a PR by @adwinwhite to weaken overflow errors to be future compatibility warnings instead. This is necessary as the old trait solver cache did not track the required recursion depth correctly. This fix is unfortunately slightly too weak so most of the breakage of the last crater run is due to overflow errors. We're have ideas how to fix this and have discussed it on zulip.

We're currently doing a lot of performance work with the new solver. @nnethercote came in and provided a 40% performance improvements for the slowest crates found by @lqd's analysis without any change in behavior in rust-lang/rust#160005. rust-lang/rust#160073 is a related minor perf improvement by @panstromek.

We merged two fixes to cycle handling with rust-lang/rust#155388 rust-lang/rust#155914. @adwinwhite simplified the TypeOutlives handling code in rust-lang/rust#159649. rust-lang/rust#158731 introduced a bug in the ProofTreeVisitor which was fixed by @amirHdev in rust-lang/rust#159772. @adwinwhite fixed a minor issue affecting clippy in rust-lang/rust#159818. He also reviewed rust-lang/rust#159840 by @Gri-ffin which also fixes a clippy issue. @bit-aloo fixed rigid alias handling in two spots in rust-lang/rust#160125.

@nnethercote

This week has mainly seen a huge amount of performance work which has not been merged yet. There are two large improvements by @nnethercote rust-lang/rust#160479 rust-lang/rust#160605. A change by @obi1kenobi rust-lang/rust#160539. Two PRs by @jdonszelmann rust-lang/rust#158436 rust-lang/rust#159025 which are blocked on rust-lang/rust#158447. A small improvement by @ChayimFriedman2 rust-lang/rust#160160.

I don't have a perfect sense of the current status and there's a lot of ongoing work, but it is looking absolutely amazing. @lqd did a complete perf run for the most downloaded 20k crates on crates.io. @jdonszelmann reran the 1000 slowest crates from that and apparently all but 15 of them are now faster than with the old solver and the worst regression is now only 1.21x times slower 🎉 That is somewhat unbelievable to us and while there is some technical nuance here, the results are just genuinely very good.

We merged the improvement to the overflow error FCW by @adwinwhite rust-lang/rust#160254 and did another crater run with it. We're down to less than 500 broken crates, with a lot of them being due to intended breakage to old bevy and minijinja versions or because they use feature(generic_const_exprs). We will triage the remaining breakage over the next weeks.

The only remaining big issue I was aware of was that our changes to opaque type handling exposed a type system unsoundness. @tiif has been working on this for a while and I ended up finishing her work in rust-lang/rust#160491.

We also merged a few smaller PRs by @adwinwhite. He fixed an ICE in clippy in #159818, removed a duplicate method in
rust-lang/rust#159836, and avoided an unnecessary query cycle rust-lang/rust#160119. @bit-aloo fixed 2 minor bugs due to the rigid alias refactor in rust-lang/rust#160125. @khyperia moved some normalization code out of generalization rust-lang/rust#160443.

Given the very good state we're in right now, I've decided against doing a separate blogpost before we enable the new solver by default and expect to just enable it by default, publishing a single call for testing at that point. My goal is the end of next-week or the start of the next.

@jdonszelmann

Since last week we've continued to do a lot of performance work with a bunch of the PRs mentioned last week now being merged. We're continuing to work on the remaining performance regressions and intend to enable it on nightly by default before the next update. We've merged rust-lang/rust#158436, rust-lang/rust#158447 by @jdonszelmann, rust-lang/rust#160479, rust-lang/rust#160605, rust-lang/rust#160801, rust-lang/rust#160673, and rust-lang/rust#160886 by @nnethercote, and rust-lang/rust#160539 by @obi1kenobi.

We've mainly focussed on large regressions found on crates.io instead of the specific tests in our benchmark suite. E.g. see rust-lang/rust#160479 (comment) where this single PR improved instruction counts for nacl-0.5.3 by more than 37%. Even so, the last week has also pretty good for our current benchmarks, see the total improvements over the last week.

We also landed a few other PRs. I merged the initial cleanup for my opaque type implied bounds soundness fix in rust-lang/rust#160504, @khyperia did a small MIR normalization cleanup in rust-lang/rust#160608, and @VicenteGusmao fixed an issue in our proof tree visitors which only affects feature(non_lifetime_binders) in rust-lang/rust#154329.

There are a bunch more PRs in flight which we should land soon and I am currently finishing up the announcement blogpost which will also contain a nice overview of our current performance impact.

@bors

We didn't quite get to enable the new trait solver on nightly before this update. The announcement blog post is ready. We changed rustc-perf to continue to run the existing tests with the old solver rust-lang/rustc-perf#2537 and the PR enabling it by default also passes CI rust-lang/rust#160619.

Merging that PR is currently blocked on a submodule sync of rustc-perf https://github.com/rust-lang/rust/pull/161344s. We're now only blocked on @bors actually merging things! Thank you @Kobzol for your help.

With this done, we'll now continue to improve the compile-time performance of the new solver while fixing a bunch of minor issues. We will also start working on the stabilization proposal. @carlini has been using an LLM to find multiple soundness issues in next-generation trait solver, but also more generally in Rust. See this zulip thread. The ones I've seen up until now are all quite localized implementation issues and should be fairly straightforward to fix. This is something we should definitely do 🤣

While I've been working towards enabling the next-solver on nightly, there also continued to be a bunch of performance work! The following PRs have been merged this week:

@jdonszelmann stop using fully_perform_locally with the next solver, it's worse (perf fix for unic-ucd) rust#160982 fixed the unic-ucd regression. It went from being 212x slower to now being pretty much exactly as fast.
@nnethercote Avoid allocations when canonicalizing rust#161077 results in an up to 3.4% performance improvement
@nnethercote Inline some hot new-solver functions rust#160892 seems to mainly matter when benchmarking locally as it tends to already be handled by PGO.

We also merged a few other more self-contained improvements to the trait solver:

@sjwang05 enable next solver by default in orphanck rust#160668. When stabilizing the next-generation trait solver in coherence checking in early 2025 stabilize -Znext-solver=coherence again rust#130654 I forgot to also enable it for the orphan-check
@Jamesbarford Move LateParamRegion to rustc_type_ir rust#160986
@adwinwhite Replace infers and non-rigid aliases with Ty/Const::Error if param env normalization fails rust#160856
@zedddie propagate RerunNonErased in projection_may_match rust#161080 fixed an ICE when encountering non-trivial constants in super-trait bounds of trait objects
@lcnr only next-solver: move implied bounds computation out of borrowck rust#161047 fixes the opaque type implied bounds unsoundness with the next-trait solver. I still need to start the Types FCP for move implied bounds computation out of borrowck rust#160491 and then also use this new approach in the old solver.
@lsunsi Add regression test for trait on next solver rust#161170 @zakrad Add regression test for normalization failure on erased closure in async block rust#161278

I intend to start the actual stabilization by October. Whether this happens depends on whether enabling the trait solver by default uncovers any major issues :>

@Kivooeo

The new trait solver is enabled on nightly by default since last Friday! See the announcement blog post for more information. The PR for this was rust-lang/rust#160619 by @Kivooeo.

Enabling the new trait solver is breaking stuff. We are triaging the issue reports as they come in. The good news is that most breakage is intended, mainly rust-lang/trait-system-refactor-initiative#168. I've opened fixes to affected crates in two cases, rust-lang/rust#161575 and rust-lang/rust#161695. In general, the fallout has been roughly as expected and I still feel good about working towards the stabilization of the new solver during the next month. I was worried we'd have to immediately move back to the old solver as the new solver still causes too many issues. This is luckily not the case.

The biggest issue I am still aware of is rust-lang/rust#161748. We're looking into this on zulip. The additional information tracked in the SearchGraph to make caching correct wrt incremental compilation can be incredibly large in some cases.

I've collaborated with @adwinwhite to improve the recursion_depth_exceeding_limit lint. This fixes the breakage in bevy_render and significantly improves the UX by only emitting this lint once per crate instead of thousands of times 😁 rust-lang/rust#161341 and rust-lang/rust#161552

We've also continued to improve the performance with the next-generation trait solver:

@xmakro perf: Push nominal obligations instead of returning them rust#160473 improving both the old and new solver by up to 2%
@nnethercote Optimize DeepRejectCtxt rust#161211 improves both solvers by nearly 1% when compiling bitmaps
Fix ordering for default impl check in the new solver rust#161268 unfortunately caused a minor bug which @nnethercote fixed in Fix ordering for default impl check in the new solver rust#161268. We expected that to slightly regress performance but it apparently doesn't. I am confused here xd

We also had a few other self-contained PRs

@spirali Error on projection of dyn noncompat type in old trait solver rust#154992 uplifts some intended behavior to the old trait solver
@Dnreikronos borrowck: Normalize non-rigid aliases in NLL type relating rust#161012 fixes a minor issue from the rigid alias refactor
@ada4a Derive GenericTypeVisitable for RegionConstraint _correctly_ rust#160914 is necessary for RustAnalyzer
@lqd Add some rustc_type_ir comments rust#161444
@nnethercote Add two comments relating to new-solver performance rust#161631

@laundmo

The new trait solver has been enabled by default for 2 weeks now. We continued to get a few more issues for it, but it continues to look quite good. I've also directly reached out to people working at large companies to get them to internally test the new trait solver. Their reports have also been very good!

I have started to work on the stabilization documentation which sure is a lot :o who would have expected that for something that multiple people have worked on for more than 3.5 years. See the trait-system-refactor-initiative repo for their current state. I intend to continue to write this and then repeatedly represent to other Types Team members to figure out where they need additional context or deep dives.

The only major issue we encountered were memory-use regressions affecting bevy_render, zerocopy, and quite a few others. The underlying reason here is that the trait solver tracks the NestedGoals accessed when computing a goal. This is necessary to be sound wrt incremental compilation. However, it does cause the trait solver to effectly require O(n^2) memory, where n is the number of nested goals. This is not an issue in most crates, but has a huge cost for a few outliers. We merged a PR by @laundmo which reduces the required memory by up to 7x here in rust-lang/rust#162031. The behavior is still quadratic, causing at least one reproducer to still OOM. We're currently discussing more involved algorithmic improvements on zulip.

We also continued to generally improve the trait solver and merged a few other PRs:

@ShoyuVanilla

Things continue to look good. We keep fixing remaining issues and are working towards stabilization. @ShoyuVanilla has been making good progress on an involved change to opaque type handling which will avoid breaking the following snippet when enabling the new solver: rust-lang/rust#161414

fn foo() -> impl IntoIterator<Item = i32> {
    if false {
        foo().into_iter().next().unwrap().abs();
    }

    vec![1]
}

I've been traveling a bunch this week so I haven't made much progress on the stabilization documentation. I did have a lot of fruitful conversations with @BoxyUwU however :3 It's really exciting just how many people are involved with the new solver right now, so even with me being less proactive, there's just a lot going on with the new solver:

@sjwang05 remove more trivial regions in evaluate_added_goals_and_make_canonical_response rust#162032 fixes the varisat hang even for old versions
@amirHdev delay unexpected successful goal during ambiguity reporting rust#162182 which unfortunely triggered a larger edge-case of the type system and we've been discussing that one on zulip
@Jamesbarford Remove RegionExt; move methods to Region in rustc_type_ir rust#160509
@lsunsi Fix unsoundness bug on next trait solver for dyn const generics placeholder rust#162475
@chenyukang Clean up on upvar_tys rust#162489
@sjwang05 Avoid manually instantiating some binders in error reporting with -Znext-solver rust#162262
@ada4a Add tests and docs for #[derive(GenericTypeVisitable)] rust#161806
@ShoyuVanilla Add a revision for previously fixed solver issue rust#162518
@lcnr remove outdated next-solver handling rust#162180 add next-solver FIXMEs rust#162431

@ShoyuVanilla

I continued to write the stabilization documentation for the new solver and we discussed the changes to normalization in this weeks Types Team meeting. It'll still take me about 2 weeks to finish these documents.

We're close to merging an improvement to our opaque type handling by @ShoyuVanilla in rust-lang/rust#161414. This should fix the only remaining behavior regression of our new opaque type handling.

@sjwang05 fixed a soundness bug in the builtin trait object impls of the new solver in rust-lang/rust#160831.

@adwinwhite fixed two issues related to overflow handling:

Eagerly report overflow errors in normalization query rust#161654 fixes a soundness bug with the new solver
-Znext-solver : Abort on the first overflowed obligation in fulfillment rust#162223

@jdonszelmann has been looking into our inference variable handling:

We also had a few smaller PRs related to the next-solver:

@bit-aloo

I continued to work on the stabilization documentation and am nearly done by now. We'll discuss it in the next types team meetings and I intend to then start the FCP in a week or two. See https://github.com/rust-lang/trait-system-refactor-initiative/blob/main/notes/stabilization-report/meta.md for the up-to-date docs.

We also had a few self-contained changes this week:

@bit-aloo Avoid leaking opaque hidden types via auto trait candidates rust#159589 is something which would have been incredibly difficult with the old solver and it's cool to see that this is a fairly straightforward change with the new one
@Dnreikronos traits: Fix rigid alias liveness matching rust#160212
@amirHdev Normalize non-rigid aliases in ty_known_to_outlive rust#161246
@khyperia yeet alias new_from_def_id rust#162760 yeet AliasConstKind::opt_def_id rust#162797
@Jamesbarford Move Const from rustc_middle to rustc_type_ir rust#162628
@lcnr treat inductive cycles as ambig rust#163159 temporarily removes a change unnecessary for the new solver stabilization, remove old solver use of SolverRelating rust#163108, remove unnecessary restriction with next-solver rust#163102, normalize normalizes, avoid next-solver hack rust#163100
@ChayimFriedman2 Provide a supertrait_def_ids() function in rustc_type_ir's interner rust#161435 will make the new solver slightly faster in RustAnalyzer

@adwinwhite

I have effectively finished the stabilization documents and we've discussed them during the last two Types Team meetings. We went through all the changes to our test suite and are going through all open GitHub issues about the new solver to make sure we're not missing anything and to properly document the impact of stabilizing the new solver.

I unfortunately messed up the last crater run, see this zulip thread for more ✨ We still need to go through that a crater run to make sure there are no new large unexpected regressions. I expect to start the stabilization FCP during the next 2 weeks. Either right before or right after EuroRust.

I've opened a lot of PRs this week to prepare our test-suite for the impending stabilization:

There have also been a bunch of other PRs during the last two weeks:

@adwinwhite
- Avoid computing overflowed goal chains for crate dependencies rust#163064 reduces the perf impact of Tracking issue for future-compatibility warning recursion_depth_exceeding_limit rust#159228
- Do not increase recursion depth for coroutine witness and rigid opaques when proving auto traits rust#162275 causes that FCW to trigger less frequently
@ShoyuVanilla
@panstromek outline unreachable! from Clause::kind rust#163657 is a small perf win
@bit-aloo Don't merge distinct impl candidates rust#161386
@sjwang05
- properly decrement available_depth on cycles and provisional cache hits rust#163185 fixes a caching bug
- Rip out old solver coherence rust#161491
- only rerun const eval in next-solver if the const actually references opaques rust#161380 improves the compile times of ReShell by 3 times.
@Dnreikronos trait_selection: Preserve eager normalization failures rust#162618
@amirHdev avoid accessing uninferred closure upvars in diagnostics rust#162595 merge candidate responses equal except for region constraints rust#162380 preserve overflow in builtin Field candidates rust#162332
@dianne next solver: prefer to select impl candidates over global where-clause candidates rust#162655
@lcnr
- fix VisibleForLeakCheck in RegionOutlives fast path rust#163267
- cycle handling: mirror old solver rust#163496 reduces the scope of the initial stabilization
- fix VisibleForLeakCheck in RegionOutlives fast path rust#163267
- add fast path to generalization rust#163607 significantly improves the performance for some crates
- optimize empty NestedGoals::extend_from_child rust#163610 is a far smaller perf improvement
- fix ValidateBoundVars rust#163612 and avoid trivial fn map_bound validations rust#163638 improve the type system performance for builds of rustc with debug_assertions enabled
- yeet compare-mode-coherence rust#163660
- explicitly check for fresh vars in canonicalize rust#163874 strenghens an internal assertion

Stabilization PR and FCP for 1.101 is in rust-lang/rust#164209! 🎉

Navigation Menu

Repository navigation

Stabilize the next-generation trait solver #113

Summary

35 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Stabilize the next-generation trait solver #113

Description

Summary

Activity

nikomatsakis commented on Jul 25, 2024

lcnr commented on Aug 1, 2024

lcnr commented on Sep 2, 2024

lcnr commented on Oct 8, 2024

lcnr commented on Nov 19, 2024

lcnr commented on Dec 19, 2024

nikomatsakis commented on Feb 18, 2025

35 remaining items

lcnr commented on Jul 14, 2026

lcnr commented on Jul 24, 2026

lcnr commented on Jul 31, 2026

lcnr commented on Aug 6, 2026

lcnr commented on Aug 13, 2026

lcnr commented on Aug 20, 2026

lcnr commented on Aug 27, 2026

lcnr commented on Sep 3, 2026

lcnr commented on Sep 11, 2026

lcnr commented on Sep 18, 2026

lcnr commented on Sep 28, 2026

lcnr commented on Oct 8, 2026

lcnr commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions