Stabilize `async fn` and return-position `impl Trait` in trait #115822

compiler-errors · 2023-09-13T18:03:23Z

Stabilization report

This report proposes the stabilization of #![feature(return_position_impl_trait_in_trait)] (RPITIT) and #![feature(async_fn_in_trait)] (AFIT). These are both long awaited features that increase the expressiveness of the Rust language and trait system.

Closes #91611

Updates from thread

The thread has covered two major concerns:

Given that we don't have RTN, what should we stabilize? -- proposed resolution is adding a lint and careful messaging
Interaction between outlives bounds and capture semantics -- This is fixable in a forwards-compatible way via Consider alias bounds when computing liveness in NLL (and opaque captures) #116040, and also eventually via ATPIT.

Stabilization Summary

This stabilization allows the following examples to work.

Example of return-position `impl Trait` in trait definition

trait Bar {
    fn bar(self) -> impl Send;
}

This declares a trait method that returns some type that implements Send. It's similar to writing the following using an associated type, except that the associated type is anonymous.

trait Bar {
    type _0: Send;
    fn bar(self) -> Self::_0;
}

Example of return-position `impl Trait` in trait implementation

impl Bar for () {
    fn bar(self) -> impl Send {}
}

This defines a method implementation that returns an opaque type, just like RPIT does, except that all in-scope lifetimes are captured in the opaque type (as is already true for async fn and as is expected to be true for RPIT in Rust Edition 2024), as described below.

Example of `async fn` in trait

trait Bar {
    async fn bar(self);
}

impl Bar for () {
    async fn bar(self) {}
}

This declares a trait method that returns some Future and a corresponding method implementation. This is equivalent to writing the following using RPITIT.

use core::future::Future;

trait Bar {
    fn bar(self) -> impl Future<Output = ()>;
}

impl Bar for () {
    fn bar(self) -> impl Future<Output = ()> { async {} }
}

The desirability of this desugaring being available is part of why RPITIT and AFIT are being proposed for stabilization at the same time.

Motivation

Long ago, Rust added RPIT and async/await. These are major features that are widely used in the ecosystem. However, until now, these feature could not be used in traits and trait implementations. This left traits as a kind of second-class citizen of the language. This stabilization fixes that.

`async fn` in trait

Async/await allows users to write asynchronous code much easier than they could before. However, it doesn't play nice with other core language features that make Rust the great language it is, like traits. Support for async fn in traits has been long anticipated and was not added before due to limitations in the compiler that have now been lifted.

async fn in traits will unblock a lot of work in the ecosystem and the standard library. It is not currently possible to write a trait that is implemented using async fn. The workarounds that exist are undesirable because they require allocation and dynamic dispatch, and any trait that uses them will become obsolete once native async fn in trait is stabilized.

We also have ample evidence that there is demand for this feature from the async-trait crate, which emulates the feature using dynamic dispatch. The async-trait crate is currently the #5 async crate on crates.io ranked by recent downloads, receiving over 78M all-time downloads. According to a recent analysis, 4% of all crates use the #[async_trait] macro it provides, representing 7% of all function and method signatures in trait definitions on crates.io. We think this is a lower bound on demand for the feature, because users are unlikely to use #[async_trait] on public traits on crates.io for the reasons already given.

Return-position `impl Trait` in trait

async fn always desugars to a function that returns impl Future.

async fn foo() -> i32 { 100 }

// Equivalent to:
fn foo() -> impl Future<Output = i32> { async { 100 } }

All async fns today can be rewritten this way. This is useful because it allows adding behavior that runs at the time of the function call, before the first .await on the returned future.

In the spirit of supporting the same set of features on async fn in traits that we do outside of traits, it makes sense to stabilize this as well. As described by the RPITIT RFC, this includes the ability to mix and match the equivalent forms in traits and their corresponding impls:

trait Foo {
    async fn foo(self) -> i32;
}

// Can be implemented as:
impl Foo for MyType {
    fn foo(self) -> impl Future<Output = i32> {
        async { 100 }
    }
}

Return-position impl Trait in trait is useful for cases beyond async, just as regular RPIT is. As a simple example, the RFC showed an alternative way of writing the IntoIterator trait with one fewer associated type.

trait NewIntoIterator {
    type Item;
    fn new_into_iter(self) -> impl Iterator<Item = Self::Item>;
}

impl<T> NewIntoIterator for Vec<T> {
    type Item = T;
    fn new_into_iter(self) -> impl Iterator<Item = T> {
        self.into_iter()
    }
}

Major design decisions

This section describes the major design decisions that were reached after the RFC was accepted:

EDIT: Lint against async fn in trait definitions
- Until the send bound problem is resolved, the use of async fn in trait definitions could lead to a bad experience for people using work-stealing executors (by far the most popular choice). However, there are significant use cases for which the current support is all that is needed (single-threaded executors, such as those used in embedded use cases, as well as thread-per-core setups). We are prioritizing serving users well over protecting people from misuse, and therefore, we opt to stabilize the full range of functionality; however, to help steer people correctly, we are will issue a warning on the use of async fn in trait definitions that advises users about the limitations. (See this summary comment for the details of the concern, and this comment for more details about the reasoning that led to this conclusion.)
Capture rules:
- The RFC's initial capture rules for lifetimes in impls/traits were found to be imprecisely precise and to introduce various inconsistencies. After much discussion, the decision was reached to make -> impl Trait in traits/impls capture all in-scope parameters, including both lifetimes and types. This is a departure from the behavior of RPITs in other contexts; an RFC is currently being authored to change the behavior of RPITs in other contexts in a future edition.
- Major discussion links:
  - Lang team design meeting from 2023-07-26
Refinement:
- The refinement RFC initially proposed that impl signatures that are more specific than their trait are not allowed unless the #[refine] attribute was included, but left it as an open question how to implement this. The stabilized proposal is that it is not a hard error to omit #[refine], but there is a lint which fires if the impl's return type is more precise than the trait. This greatly simplified the desugaring and implementation while still achieving the original goal of ensuring that users do not accidentally commit to a more specific return type than they intended.
- Major discussion links:
  - Zulip thread

What is stabilized

Async functions in traits and trait implementations

async fn are now supported in traits and trait implementations.
Associated functions in traits that are async may have default bodies.

Return-position impl trait in traits and trait implementations

Return-position impl Traits are now supported in traits and trait implementations.
- Return-position impl Trait in implementations are treated like regular return-position impl Traits, and therefore behave according to the same inference rules for hidden type inference and well-formedness.
Associated functions in traits that name return-position impl Traits may have default bodies.
Implementations may provide either concrete types or impl Trait for each corresponding impl Trait in the trait method signature.

For a detailed exploration of the technical implementation of return-position impl Trait in traits, see the dev guide.

Mixing `async fn` in trait and return-position `impl Trait` in trait

A trait function declaration that is async fn ..() -> T may be satisfied by an implementation function that returns impl Future<Output = T>, or vice versa.

trait Async {
    async fn hello();
}

impl Async for () {
    fn hello() -> impl Future<Output = ()> {
        async {}
    }
}

trait RPIT {
    fn hello() -> impl Future<Output = String>;
}

impl RPIT for () {
    async fn hello() -> String {
        "hello".to_string()
    }
}

Return-position `impl Trait` in traits and trait implementations capture all in-scope lifetimes

Described above in "major design decisions".

Return-position `impl Trait` in traits are "always revealing"

When a trait uses -> impl Trait in return position, it logically desugars to an associated type that represents the return (the actual implementation in the compiler is different, as described below). The value of this associated type is determined by the actual return type written in the impl; if the impl also uses -> impl Trait as the return type, then the value of the associated type is an opaque type scoped to the impl method (similar to what you would get when calling an inherent function returning -> impl Trait). As with any associated type, the value of this special associated type can be revealed by the compiler if the compiler can figure out what impl is being used.

For example, given this trait:

trait AsDebug {
    fn as_debug(&self) -> impl Debug;
}

A function working with the trait generically is only able to see that the return value is Debug:

fn foo<T: AsDebug>(t: &T) {
    let u = t.as_debug();
    println!("{}", u); // ERROR: `u` is not known to implement `Display`
}

But if a function calls as_debug on a known type (say, u32), it may be able to resolve the return type more specifically, if that implementation specifies a concrete type as well:

impl AsDebug for u32 {
    fn as_debug(&self) -> u32 {
        *self
    }
}

fn foo(t: &u32) {
    let u: u32 = t.as_debug(); // OK!
    println!("{}",  t.as_debug()); // ALSO OK (since `u32: Display`).
}

The return type used in the impl therefore represents a semver binding promise from the impl author that the return type of <u32 as AsDebug>::as_debug will not change. This could come as a surprise to users, who might expect that they are free to change the return type to any other type that implements Debug. To address this, we include a refining_impl_trait lint that warns if the impl uses a specific type -- the impl AsDebug for u32 above, for example, would toggle the lint.

The lint message explains what is going on and encourages users to allow the lint to indicate that they meant to refine the return type:

impl AsDebug for u32 {
    #[allow(refining_impl_trait)]
    fn as_debug(&self) -> u32 {
        *self
    }
}

RFC #3245 proposed a new attribute, #[refine], that could also be used to "opt-in" to refinements like this (and which would then silence the lint). That RFC is not currently implemented -- the #[refine] attribute is also expected to reveal other details from the signature and has not yet been fully implemented.

Return-position `impl Trait` and `async fn` in traits are opted-out of object safety checks when the parent function has `Self: Sized`

trait IsObjectSafe {
    fn rpit() -> impl Sized where Self: Sized;
    async fn afit() where Self: Sized;
}

Traits that mention return-position impl Trait or async fn in trait when the associated function includes a Self: Sized bound will remain object safe. That is because the associated function that defines them will be opted-out of the vtable of the trait, and the associated types will be unnameable from any trait object.

This can alternatively be seen as a consequence of #112319 (comment) and the desugaring of return-position impl Trait in traits to associated types which inherit the where-clauses of the associated function that defines them.

What isn't stabilized (aka, potential future work)

Dynamic dispatch

As stabilized, traits containing RPITIT and AFIT are not dyn compatible. This means that you cannot create dyn Trait objects from them and can only use static dispatch. The reason for this limitation is that dynamic dispatch support for RPITIT and AFIT is more complex than static dispatch, as described on the async fundamentals page. The primary challenge to using dyn Trait in today's Rust is that dyn Trait today must list the values of all associated types. This means you would have to write dyn for<'s> Trait<Foo<'s> = XXX> where XXX is the future type defined by the impl, such as F_A. This is not only verbose (or impossible), it also uniquely ties the dyn Trait to a particular impl, defeating the whole point of dyn Trait.

The precise design for handling dynamic dispatch is not yet determined. Top candidates include:

callee site selection, in which we permit unsized return values so that the return type for an -> impl Foo method be can be dyn Foo, but then users must specify the type of wide pointer at the call-site in some fashion.
dyn*, where we create a built-in encapsulation of a "wide pointer" and map the associated type corresponding to an RPITIT to the corresponding dyn* type (dyn* itself is not exposed to users as a type in this proposal, though that could be a future extension).

Where-clause bounds on return-position `impl Trait` in traits or async futures (RTN/ART)

One limitation of async fn in traits and RPITIT as stabilized is that there is no way for users to write code that adds additional bounds beyond those listed in the -> impl Trait. The most common example is wanting to write a generic function that requires that the future returned from an async fn be Send:

trait Greet {
    async fn greet(&self);
}

fn greet_in_parallel<G: Greet>(g: &G) {
    runtime::spawn(async move {
        g.greet().await; //~ ERROR: future returned by `greet` may not be `Send`
    })
}

Currently, since the associated types added for the return type are anonymous, there is no where-clause that could be added to make this code compile.

There have been various proposals for how to address this problem (e.g., return type notation or having an annotation to give a name to the associated type), but we leave the selection of one of those mechanisms to future work.

In the meantime, there are workarounds that one can use to address this problem, listed below.

Require all futures to be `Send`

For many users, the trait may only ever be used with Send futures, in which case one can write an explicit impl Future + Send:

trait Greet {
    fn greet(&self) -> impl Future<Output = ()> + Send;
}

The nice thing about this is that it is still compatible with using async fn in the trait impl. In the async working group case studies, we found that this could work for the builder provider API. This is also the default approach used by the #[async_trait] crate which, as we have noted, has seen widespread adoption.

Avoid generics

This problem only applies when the Self type is generic. If the Self type is known, then the precise return type from an async fn is revealed, and the Send bound can be inferred thanks to auto-trait leakage. Even in cases where generics may appear to be required, it is sometimes possible to rewrite the code to avoid them. The socket handler refactor case study provides one such example.

Unify capture behavior for `-> impl Trait` in inherent methods and traits

As stabilized, the capture behavior for -> impl Trait in a trait (whether as part of an async fn or a RPITIT) captures all types and lifetimes, whereas the existing behavior for inherent methods only captures types and lifetimes that are explicitly referenced. Capturing all lifetimes in traits was necessary to avoid various surprising inconsistencies; the expressed intent of the lang team is to extend that behavior so that we also capture all lifetimes in inherent methods, which would create more consistency and also address a common source of user confusion, but that will have to happen over the 2024 edition. The RFC is in progress. Should we opt not to accept that RFC, we can bring the capture behavior for -> impl Trait into alignment in other ways as part of the 2024 edition.

`impl_trait_projections`

Orthgonal to async_fn_in_trait and return_position_impl_trait_in_trait, since it can be triggered on stable code. This will be stabilized separately in #115659.

If we try to write this code without `impl_trait_projections`, we will get an error:

#![feature(async_fn_in_trait)]

trait Foo {
    type Error;
    async fn foo(&mut self) -> Result<(), Self::Error>;
}

impl<T: Foo> Foo for &mut T {
    type Error = T::Error;
    async fn foo(&mut self) -> Result<(), Self::Error> {
        T::foo(self).await
    }
}

The error relates to the use of Self in a trait impl when the self type has a lifetime. It can be worked around by rewriting the impl not to use Self:

#![feature(async_fn_in_trait)]

trait Foo {
    type Error;
    async fn foo(&mut self) -> Result<(), Self::Error>;
}

impl<T: Foo> Foo for &mut T {
    type Error = T::Error;
    async fn foo(&mut self) -> Result<(), <&mut T as Foo>::Error> {
        T::foo(self).await
    }
}

Tests

Tests are generally organized between return-position impl Trait and async fn in trait, when the distinction matters.

Remaining bugs and open issues

Failed to normalize async_fn_in_trait ICE for indirect recursion of async trait method calls #112047: Indirection introduced by async fn and return-position impl Trait in traits may hide cycles in opaque types, causing overflow errors that can only be discovered by monomorphization.
RPITIT with Send trait marker breaks borrow checker #111105 - async fn in trait is susceptible to issues with checking auto traits on futures' generators, like regular async. This is a manifestation of Tracking issue for incorrect lifetime bound errors in async #110338.
- This was deemed not blocking because fixing it is forwards-compatible, and regular async is subject to the same issues.
AFIT: impl can't add extra lifetime restrictions, unlike non-async #104689: async fn and return-position impl Trait in trait requires the late-bound lifetimes in a trait and impl function signature to be equal.
- This can be relaxed in the future with a smarter lexical region resolution algorithm.
Exponential compile times for chained RPITIT #102527: Nesting return-position impl Trait in trait deeply may result in slow compile times.
- This has only been reported once, and can be fixed in the future.
type inference fails when using async_fn_in_trait #108362: Inference between return types and generics of a function may have difficulties when there's an .await.
- This isn't related to AFIT (type inference fails when using async_fn_in_trait #108362 (comment)) -- using traits does mean that there's possibly easier ways to hit it.
AFIT: strange errors on circular impls #112626: Because async fn and return-position impl Trait in traits lower to associated types, users may encounter strange behaviors when implementing circularly dependent traits.
- This is not specific to RPITIT, and is a limitation of associated types: AFIT: strange errors on circular impls #112626 (comment)
(Nightly) Weird interaction between specialization and RPITITs #108309: async fn and return-position impl Trait in trait do not support specialization. This was deemed not blocking, since it can be fixed in the future (e.g. Do project specializable RPITIT projection #108321) and specialization is a nightly feature.

(Nightly) Return type notation bugs

RTN is not being stabilized here, but there are some interesting outstanding bugs. None of them are blockers for AFIT/RPITIT, but I'm noting them for completeness.

hrtb + infer types break auto traits with return type notation #109924 is a bug that occurs when a higher-ranked trait bound has both inference variables and associated types. This is pre-existing -- RTN just gives you a more convenient way of producing them. This should be fixed by the new trait solver.
hrtb + infer types break auto traits with return type notation #109924 is a manifestation of a more general issue with async and auto-trait bounds: Tracking issue for incorrect lifetime bound errors in async #110338. RTN does not cause this issue, just allows us to put Send bounds on the anonymous futures that we have in traits.
async_fn_in_trait and return_type_notation cause awkward awaits #112569 is a bug similar to associated type bounds, where nested bounds are not implied correctly.

Alternatives

Do nothing

We could choose not to stabilize these features. Users that can use the #[async_trait] macro would continue to do so. Library maintainers would continue to avoid async functions in traits, potentially blocking the stable release of many useful crates.

Stabilize `impl Trait` in associated type instead

AFIT and RPITIT solve the problem of returning unnameable types from trait methods. It is also possible to solve this by using another unstable feature, impl Trait in an associated type. Users would need to define an associated type in both the trait and trait impl:

trait Foo {
    type Fut<'a>: Future<Output = i32> where Self: 'a;
    fn foo(&self) -> Self::Fut<'_>;
}

impl Foo for MyType {
    type Fut<'a> where Self: 'a = impl Future<Output = i32>;
    fn foo(&self) -> Self::Fut<'_> {
        async { 42 }
    }
}

This also has the advantage of allowing generic code to bound the associated type. However, it is substantially less ergonomic than either async fn or -> impl Future, and users still expect to be able to use those features in traits. Even if this feature were stable, we would still want to stabilize AFIT and RPITIT.

That said, we can have both. impl Trait in associated types is desireable because it can be used in existing traits with explicit associated types, among other reasons. We should stabilize this feature once it is ready, but that's outside the scope of this proposal.

Use the old capture semantics for RPITIT

We could choose to make the capture rules for RPITIT consistent with the existing rules for RPIT. However, there was strong consensus in a recent lang team meeting that we should change these rules, and furthermore that new features should adopt the new rules.

This is consistent with the tenet in RFC 3085 of favoring "Uniform behavior across editions" when possible. It greatly reduces the complexity of the feature by not requiring us to answer, or implement, the design questions that arise out of the interaction between the current capture rules and traits. This reduction in complexity – and eventual technical debt – is exactly in line with the motivation listed in the aforementioned RFC.

Make refinement a hard error

Refinement (refining_impl_trait) is only a concern for library authors, and therefore doesn't really warrant making into a deny-by-default warning or an error.

Additionally, refinement is currently checked via a lint that compares bounds in the impl Traits in the trait and impl syntactically. This is good enough for a warning that can be opted-out, but not if this were a hard error, which would ideally be implemented using fully semantic, implicational logic. This was implemented (#111931), but also is an unnecessary burden on the type system for little pay-off.

History

Dec 7, 2021: RFC #3185: Static async fn in traits merged
Sep 9, 2022: Initial implementation of AFIT and RPITIT landed
Jun 13, 2023: RFC #3425: Return position impl Trait in traits merged

Non-exhaustive list of PRs that are particularly relevant to the implementation:

Doc co-authored by @nikomatsakis, @tmandry, @traviscross. Thanks also to @spastorino, @cjgillot (for changes to opaque captures!), @oli-obk for many reviews, and many other contributors and issue-filers. Apologies if I left your name off 😺

rustbot · 2023-09-13T18:03:35Z

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

rustbot · 2023-09-13T18:03:39Z

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

nikomatsakis · 2023-09-13T20:07:59Z

withoutboats · 2023-09-13T20:17:47Z

(NOT A CONTRIBUTION)

I am very sorry to have to write this, but I do not believe that this stabilization report should be accepted. It is based on the reversal of the previously agreed upon resolution to #103854, and there seems to be no basis for that reversal except a desire to ship to a specific schedule.

I want to reiterate my position expressed in #103854, that a solution to the "Send problem" should be considered a blocker on stabilizing AFIT. Despite eagerly awaiting the completion of AFIT, I still hold this view and I want to restate my concern. The discussion on #103854 concluded that an RTN-like solution should block stabilizing AFIT, and I do not see any facts presented here that have changed that should change that conclusion.

The proposed mitigations in this stabilization report are not adequate to resolve the problem for users.

Users cannot, in the general case, "avoid spawning in a generic context." The stabilization report cites one case study in which that mitigation was possible, but an examination of the diff shows that case study is clearly not ordinary. In that case study, an enum is being used to determine the instantiation of a generic function to one of a closed set of concrete types. Obviously, many generic functions are actually generic, in that the type parameter is being instantiated elsewhere, and "avoiding spawning in a generic context" could require enormous refactoring, possibly across multiple crate boundaries, if its possible at all.

I can speak to my own experienced writing (closed source) code, in which a bug in existing code could only be fixed by introducing a spawn. This code was generic - it was a method on a generic container - and it required calling an async method (defined using the async-trait crate) on a generic value of that type that parameterized the container. Fixing this bug if it were not possible to require that the return type of that method is Send would have not been realistically feasible. I would describe this situation as a "trap" - a user could be stuck in a situation in which they have no realistic avenue to express to the compiler that their code is valid, through no fault of their own.

One problem not addressed by the first mitigation is that users do not always control the definition of traits they use: those traits may be defined in open source libraries their project depends on. Authors of open source libraries who want to begin using AFIT will have to decide: do they use the first mitigation discussed here - requiring all of their users to impose a Send bound on these types - or do they use AFIT, exposing their users running on work stealing executors to the risk of encountering this trap?

I note especially that the transform implemented by async-trait is non-trivial, and the mitigation in the stabilization report understates the problem, because if the method includes lifetimes, expressing that dependence with impl trait syntax is not obvious. On the other hand, writing the AFIT syntax is easy. I expect library authors who are not exceptionally cautious to just use the AFIT syntax, exposing their users to the possibility of being caught in the Send-spawn trap.

What does the lang team recommend to open source library authors about how they should define traits with async methods? Does it suggest they use the first mitigation or not? Does it believe that they will do this, or does it consider library authors accidentally imposing the Send-spawn trap on end users an acceptable outcome?

Moreover, why should the position be shifted from the position adopted in #103854? What has changed in the intervening time?

I want to highlight what I see as a major process failure that has led to this situation. The reality is that the "Send method problem" has been known and discussed since 2018, when I remember discussing it with other members of the language team. Despite knowing about this problem for at least five years, it seems very little was done to try to resolve the problem before #103854 was opened less than a year ago. Why not?

RTN should have been addressed in parallel with GATs, so that AFIT would be ready to ship soon after the launch of GATs last year. The fact that it wasn't was a major process failure, one of most severe examples of the lang team failing to keep on top of its responsibilities, and I think the team should take responsibility for that.

I have the impression that this stabilization report is motivated by a desire to meet the goal stated in the blog post that async fn in traits would be stabilized in 2023. But the blog post also stated that some form of RTN would be included as a blocking requirement of that goal. Breaking previous consensus decisions about blockers to meet an arbitrary deadline should not be acceptable to the project.

workingjubilee · 2023-09-13T21:40:59Z

RTN should have been addressed in parallel with GATs, so that AFIT would be ready to ship soon after the launch of GATs last year. The fact that it wasn't was a major process failure, one of most severe examples of the lang team failing to keep on top of its responsibilities, and I think the team should take responsibility for that.

am I just out of the loop or is it the case that RTN was not even mentioned by the time the GAT stabilization proposal was accepted? there were some concerns about the lifetime problems in various positions of using GATs which were valid and that you expressed, I think, and would have been reason enough to block it, and at the time I agreed with that in particular. however, GATs and RTN, despite having some relationship (namely, RTN desugaring into associated types, including GATs), only have an underlying dependency of RTN on GATs for having a nice implementation. it is not the case that GATs are not useful in their own right or that they only live for this use-case.

it would be good if we could reserve phrases like "major process failure" for things that are unambiguously so, rather than just things that seem slightly suboptimal, unless I am wildly misunderstanding things.

nikomatsakis · 2023-09-13T21:50:05Z

@withoutboats

It is definitely a reversal of that decision. It was discussed quite a bit some time back. I wrote a blog post at the time but..

rust-lang/blog.rust-lang.org#1112

...apparently it never got merged! The reasoning there was as follows, and I think it's correct (but perhaps should be added to the stabilization report):

One of the key questions we were considering was whether to hold off on stabilizing async functions in traits until we were ready to stabilize a solution for the "send bounds" problem as well. On the one hand, our case studies showed that send bounds would be important to many users. Moreover, the stabilization of async functions in traits is going to be a big deal and many users will try using them. We don't want them to get frustrated with missing functionality.

On the other hand, a true "send bounds" solution is only needed when you wish to have a trait that may or may not return Send futures. Many users can get by with traits that either always require Send or never require Send, as demonstrated by the #[async_trait] macro.

Rust has a tradition of making new functionality available incrementally rather than waiting for perfection, and it's always served us well (async functions themselves are an example of this, as is -> impl Trait in other functions). Moreover, while it is possible to emulate async fn using -> impl Future, the translation can be subtle. We feared that releasing -> impl Trait support without async fn would lead to people misusing the former to emulate the latter. On balance, we felt that it would be better to release async functions as quickly as possible.

You wrote this:

The fact that it wasn't was a major process failure, one of most severe examples of the lang team failing to keep on top of its responsibilities, and I think the team should take responsibility for that.

I wholeheartedly agree that the stabilization schedule for async fn in trait has been too slow. In fact, early on, when we did our initial planning, @tmandry and I said from the beginning that we were going to stabilize incrementally and often, but it didn't happen, for a variety of reasons. I'd like to do a retrospective to talk about that, it's something I've been thinking about, but regardless, the main takeaway for me has definitely been we need to double down on incremental progress. And that's exactly what we're trying to do with this PR.

I definitely agree that the next step after we do this stabilization will be to focus on solving the "send bound" problem (and then probably dynamic dispatch). Personally I'm still positive on RTN, but there have been some interesting alternatives. It'll be much easier for us to have this conversation if we're not blocked.

I have the impression that this stabilization report is motivated by a desire to meet the goal stated in the blog post that async fn in traits would be stabilized in 2023. But the blog post also stated that some form of RTN would be included as a blocking requirement of that goal. Breaking previous consensus decisions about blockers to meet an arbitrary deadline should not be acceptable to the project.

Actually, I think this is backwards. Rust has always operated on a model where we deliver incrementally and continuously -- this is what the release trains are all about! -- and avoid blocking things for "big bang" releases that cover everything all at once (the edition is the major counterexample, and we explicitly moved that to a more train-based model for Rust 2021, which I think was a success). That's because grouping too much stuff together leads to stress and means users have to wait longer; it also denies us valuable feedback. I am positive that having people able to play around with async fns in traits and so forth will make it easier, not harder, for us to have the follow-on discussions we need to have.

What does the lang team recommend to open source library authors about how they should define traits with async methods? Does it suggest they use the first mitigation or not? Does it believe that they will do this, or does it consider library authors accidentally imposing the Send-spawn trap on end users an acceptable outcome?

My recommendation is that they use explicit GATs for the time being, which are stable.

(EDIT: I forget that we didn't get TAIT stabilization done yet! I was hoping to have both, which would've put us in a great place. Without that, it's a bit more painful; but I don't see how anyone's lives get worse, it just means we haven't solved all the problems for all the people yet.)

oli-obk · 2023-09-13T21:59:19Z

I do not expect this feature to solve all problems that exist around using async around traits. The foremost change of this feature is that you can use it to replace all your non-dyn uses of the async_trait crate. This means you stop paying the cost of a heap allocation per async fn method call. It does not mean you can now be generic over the sendness of the future returned by these method calls. That use case was already not supported and it still drew a lot of crates (and many more binaries) to using the async_trait proc macro.

Wrt perceived or real multiple process failures, please raise them on zulip with the lang team. This general discussion does not belong here and is off topic.

withoutboats · 2023-09-13T22:46:47Z

(NOT A CONTRIBUTION)

I do agree with this framing of the Send problem:

On the other hand, a true "send bounds" solution is only needed when you wish to have a trait that may or may not return Send futures. Many users can get by with traits that either always require Send or never require Send, as demonstrated by the #[async_trait] macro.

And if I understand correctly, the changes to lifetime capture mean that there's a relatively high degree of parity between declaring an async method with and without the Send bound. The stabilization report implies this in the mitigation section, but doesn't call it out explicitly there and I didn't consider it while writing my first comment.

In other words, I want to explicitly connect a method written with async-trait to what would be written with this feature:

#[async_trait]
trait RequiresSend {
    async fn foo(&self) -> Option<String>;
}

trait RequiresSend {
    fn foo(&self) -> impl Future<Output = Option<String>> + Send;
}

#[async_trait(?Send)]
trait NotSend {
    async fn foo(&self) -> Option<String>;
}

trait NotSend {
    async fn foo(&self) -> Option<String>;
}

So, with this as the case, there's a lot closer parity between the complexity of AlwaysSend signatures and NotSend signatures than there was without the lifetime capture changes. That's good, but I think it's still not a trivial difference.

I know the team has considered a syntax for bounding Send on all the methods of a trait (FWIW I think this is unnecessary), but what openness is there to an attribute to require Send on the return type of an AFIT without having to transform the signature to RPIT?

In other words:

trait RequiresSend {
     #[require_send]
     async fn foo(&self) -> Option<String>;
}

I think I would personally be comfortable with stabilizing this feature with an attribute like this and a strongly worded recommendation to library authors that if they want to be compatible with the work stealing runtimes they should apply this attribute. Obviously in the future when an RTN-like feature lands, discouraging this attribute would then be preferred. This would increase churn, but I think it would do a lot to reduce the risk of the Send-spawn trap.

A248 · 2023-09-14T00:34:02Z

If it's really so desired, implementing an attribute like #[require_send] can be provided via a crate. Using a crate would require less long-term baggage for the eventual time when #[require_send] becomes obsolete.

emersonford · 2023-09-14T01:37:02Z

As a +1 to @withoutboats's comment, there's three glaring issues I regularly see wrt to async + Send:

(a) It's far too easy to accidentally make a Future not Send, particularly due to #110338. From my experience, three frequent offenders for this are:

Owning a !Send value in an async block. You don't even have to hold it over an await point as -- without enabling -Zdrop-tracking -- async blocks don't currently respect dropping !Send values before an await point.
Using the wrong iterator incantation. futures::stream::iter in particular is notorious for triggering this (see the many comments on Bogus higher-ranked lifetime error in an async block #102211).
.awaiting a !Send future (which is usually !Send due to one of the above).

(b) The error messaging around why a future is !Send is at best unfriendly to beginners, at worst unintelligible for even seasoned Rust developers. If you're lucky, the compiler will spit out something like future returned by 'bar' is not 'Send', but more often than not you're greeted with something like:

   = note: `fn(&'0 ())` must implement `Trait`, for any lifetime `'0`...
   = note: ...but `Trait` is actually implemented for the type `fn(&'static ())`

which tells you nothing about what is actually triggering the future to be !Send (nor does it actually say anything about the future being !Send). I regularly have to desugar async fn blocks to fn -> impl Future<...> + Send to get any helpful error messages, which feels really bad especially if the !Send is coming from some future being awaited 3 levels down the call stack or from some dependency.

(c) From my experience, "Future is not Send" errors are often not surfaced early in the development process, and the later these errors are surfaced in the development process, the worse they feel to debug and correct due to (b). I've hit this several times when writing helper methods that I intend to call from something using tokio::spawn (e.g. a web server or pyo3's future_into_py), and it has been enough of a headache that I often forgo async fn entirely for fn blah(...) -> impl Future<...> + Send { async move { ... } } (which is often a point of confusion for team members reviewing my code).

Now none of these are unique to AFIT, but similar to @withoutboats, I'm worried stabilizing AFIT without a clear Send story is going to make this issue even worse. I've found both #[async_trait]s default Send requirement and BoxFuture's default Send requirement (the combination of which I've seen to be the most common way to do AFIT today) to help surface !Send futures earlier in the development process and help guard against !Send from infecting async code bases. Stabilizing AFIT would effectively discourage using async_trait or BoxFuture, which would eliminate a huge guard against !Send futures.

So personally, I'd like to see one of two things happen before AFIT is stabilized:

Significantly improve the ergonomics around "Future is not Send" errors.
Have a clear Send story around AFIT.

`AFIT` is expected in the upcoming rust-1.75 release (scheduled for 2023/12/28). `#[allow(async_fn_in_trait)]` is required until a solution to RPITIT is merged in rust. This put responsability on the implementor of `async_signature::AsyncSigner` to make sure their future is `Send`able. see rust-lang/rust#115822 (comment) for more context.

Using an iterator instead of a static slice allows for more flexible implementations of `TracksInfo` that can use the chain storage without compromising a lot on the performance/memory penalty if we were to return an owned `Vec` instead. NOTE: This feature will benefit from the soon to be released return_position_impl_trait_in_trait(rust-lang/rust#115822) to not require the `TracksIter` associated type and from a bugfix in the compiler(rust-lang/rust#116662) to declare the DEFAULT_MAX_TRACK_NAME_LEN generic constant in the `TracksInfo` trait.

which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822

`AFIT` is expected in the upcoming rust-1.75 release (scheduled for 2023/12/28). `#[allow(async_fn_in_trait)]` is required until a solution to RPITIT is merged in rust. This put responsability on the implementor of `async_signature::AsyncSigner` to make sure their future is `Send`able. see rust-lang/rust#115822 (comment) for more context.

`AFIT` was stabilized in Rust 1.75. `#[allow(async_fn_in_trait)]` is required until a solution to RPITIT is merged in rust. This put responsability on the implementor of `async_signature::AsyncSigner` to make sure their future is `Send`able. see rust-lang/rust#115822 (comment) for more context. Also introduces an `AsyncRandomizedSigner` trait. Co-authored-by: Arthur Gautier <arthur.gautier@arista.com>

* rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR #3039.

which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822

* rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR zellij-org#3039.

which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822

* refactor: Simplify transfer_rows_from_viewport_to_lines_above next_lines is always consolidated to a single Row, which immediately gets removed - we can remove some dead code as a result * perf: Batch remove rows from the viewport for performance Given a 1MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~9s to ~3s * perf: Optimize Row::drain_until by splitting chars in one step Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~23s to ~20s * refactor: Simplify `if let` into a `.map` * refactor: There are only new saved coordinates when there were old ones * refactor: Unify viewport transfer: use common variable names * fix: Use same saved cursor logic in height resize as width See #2182 for original introduction that only added it in one branch, this fixes an issue where the saved cursor was incorrectly reset when the real cursor was * fix: Correct saved+real cursor calculations when reflowing long lines * fix: Don't create canonical lines if cursor ends on EOL after resize Previously if a 20 character line were split into two 10 character lines, the cursor would be placed on the line after the two lines. New characters would then be treated as a new canonical line. This commit fixes this by biasing cursors to the end of the previous line. * fix: for cursor index calculation in lines that are already wrapped * chore: test for real/saved cursor position being handled separately * chore: Apply cargo format * chore(repo): update issue templates * Bump rust version to 1.75.0 (#3039) * rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR #3039. * feat(plugins): introduce 'pipes', allowing users to pipe data to and control plugins from the command line (#3066) * prototype - working with message from the cli * prototype - pipe from the CLI to plugins * prototype - pipe from the CLI to plugins and back again * prototype - working with better cli interface * prototype - working after removing unused stuff * prototype - working with launching plugin if it is not launched, also fixed event ordering * refactor: change message to cli-message * prototype - allow plugins to send messages to each other * fix: allow cli messages to send plugin parameters (and implement backpressure) * fix: use input_pipe_id to identify cli pipes instead of their message name * fix: come cleanups and add skip_cache parameter * fix: pipe/client-server communication robustness * fix: leaking messages between plugins while loading * feat: allow plugins to specify how a new plugin instance is launched when sending messages * fix: add permissions * refactor: adjust cli api * fix: improve cli plugin loading error messages * docs: cli pipe * fix: take plugin configuration into account when messaging between plugins * refactor: pipe message protobuf interface * refactor: update(event) -> pipe * refactor - rename CliMessage to CliPipe * fix: add is_private to pipes and change some naming * refactor - cli client * refactor: various cleanups * style(fmt): rustfmt * fix(pipes): backpressure across multiple plugins * style: some cleanups * style(fmt): rustfmt * style: fix merge conflict mistake * style(wording): clarify pipe permission * docs(changelog): introduce pipes * fix: add some robustness and future proofing * fix e2e tests --------- Co-authored-by: Aram Drevekenin <aram@poor.dev> Co-authored-by: har7an <99636919+har7an@users.noreply.github.com>

* rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR zellij-org#3039.

…3032) * refactor: Simplify transfer_rows_from_viewport_to_lines_above next_lines is always consolidated to a single Row, which immediately gets removed - we can remove some dead code as a result * perf: Batch remove rows from the viewport for performance Given a 1MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~9s to ~3s * perf: Optimize Row::drain_until by splitting chars in one step Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~23s to ~20s * refactor: Simplify `if let` into a `.map` * refactor: There are only new saved coordinates when there were old ones * refactor: Unify viewport transfer: use common variable names * fix: Use same saved cursor logic in height resize as width See zellij-org#2182 for original introduction that only added it in one branch, this fixes an issue where the saved cursor was incorrectly reset when the real cursor was * fix: Correct saved+real cursor calculations when reflowing long lines * fix: Don't create canonical lines if cursor ends on EOL after resize Previously if a 20 character line were split into two 10 character lines, the cursor would be placed on the line after the two lines. New characters would then be treated as a new canonical line. This commit fixes this by biasing cursors to the end of the previous line. * fix: for cursor index calculation in lines that are already wrapped * chore: test for real/saved cursor position being handled separately * chore: Apply cargo format * chore(repo): update issue templates * Bump rust version to 1.75.0 (zellij-org#3039) * rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR zellij-org#3039. * feat(plugins): introduce 'pipes', allowing users to pipe data to and control plugins from the command line (zellij-org#3066) * prototype - working with message from the cli * prototype - pipe from the CLI to plugins * prototype - pipe from the CLI to plugins and back again * prototype - working with better cli interface * prototype - working after removing unused stuff * prototype - working with launching plugin if it is not launched, also fixed event ordering * refactor: change message to cli-message * prototype - allow plugins to send messages to each other * fix: allow cli messages to send plugin parameters (and implement backpressure) * fix: use input_pipe_id to identify cli pipes instead of their message name * fix: come cleanups and add skip_cache parameter * fix: pipe/client-server communication robustness * fix: leaking messages between plugins while loading * feat: allow plugins to specify how a new plugin instance is launched when sending messages * fix: add permissions * refactor: adjust cli api * fix: improve cli plugin loading error messages * docs: cli pipe * fix: take plugin configuration into account when messaging between plugins * refactor: pipe message protobuf interface * refactor: update(event) -> pipe * refactor - rename CliMessage to CliPipe * fix: add is_private to pipes and change some naming * refactor - cli client * refactor: various cleanups * style(fmt): rustfmt * fix(pipes): backpressure across multiple plugins * style: some cleanups * style(fmt): rustfmt * style: fix merge conflict mistake * style(wording): clarify pipe permission * docs(changelog): introduce pipes * fix: add some robustness and future proofing * fix e2e tests --------- Co-authored-by: Aram Drevekenin <aram@poor.dev> Co-authored-by: har7an <99636919+har7an@users.noreply.github.com>

… reducing size of TerminalCharacter (#3043) * refactor: Simplify transfer_rows_from_viewport_to_lines_above next_lines is always consolidated to a single Row, which immediately gets removed - we can remove some dead code as a result * perf: Batch remove rows from the viewport for performance Given a 1MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~9s to ~3s * perf: Optimize Row::drain_until by splitting chars in one step Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~23s to ~20s * refactor: Simplify `if let` into a `.map` * refactor: There are only new saved coordinates when there were old ones * refactor: Unify viewport transfer: use common variable names * fix: Use same saved cursor logic in height resize as width See #2182 for original introduction that only added it in one branch, this fixes an issue where the saved cursor was incorrectly reset when the real cursor was * fix: Correct saved+real cursor calculations when reflowing long lines * fix: Don't create canonical lines if cursor ends on EOL after resize Previously if a 20 character line were split into two 10 character lines, the cursor would be placed on the line after the two lines. New characters would then be treated as a new canonical line. This commit fixes this by biasing cursors to the end of the previous line. * fix: for cursor index calculation in lines that are already wrapped * chore: test for real/saved cursor position being handled separately * chore: Apply cargo format * refactor: Unify viewport transfer: transfer + cursor update together * perf: Reduce size of TerminalCharacter from 72 to 60 bytes With a 10MB single line catted into a fresh terminal, VmRSS goes from 964092 kB to 874020 kB (as reported by /proc/<pid>/status) before/after this patch Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~15s to ~12.5s * fix(build): Don't unconditionally rebuild zellij-utils * refactor: Remove Copy impl on TerminalCharacter * perf: Rc styles to reduce TerminalCharacter from 60 to 24 bytes With a 10MB single line catted into a fresh terminal, VmRSS goes from 845156 kB to 478396 kB (as reported by /proc/<pid>/status) before/after this patch Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~12.5s to ~7s * perf: Remove RcCharacterStyles::Default, allow enum niche optimisation This reduces TerminalCharacter from 24 to 16 bytes With a 10MB single line catted into a fresh terminal, VmRSS goes from 478396 kB to 398108 kB (as reported by /proc/<pid>/status) before/after this patch Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~7s to ~4.75s * docs: link anchor omission from reset_all is deliberate reset_all is only used from ansi params, and ansi params don't control link anchor * fix: Remove no-op on variable that gets immediately dropped * refactor: Simplify replace_character_at logic The original condition checked absolute_x_index was in bounds, then used the index to manipulate it. This is equivalent to getting a ref to the character at that position and manipulating directly * chore: Run xtask format * chore(repo): update issue templates * Bump rust version to 1.75.0 (#3039) * rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR #3039. * feat(plugins): introduce 'pipes', allowing users to pipe data to and control plugins from the command line (#3066) * prototype - working with message from the cli * prototype - pipe from the CLI to plugins * prototype - pipe from the CLI to plugins and back again * prototype - working with better cli interface * prototype - working after removing unused stuff * prototype - working with launching plugin if it is not launched, also fixed event ordering * refactor: change message to cli-message * prototype - allow plugins to send messages to each other * fix: allow cli messages to send plugin parameters (and implement backpressure) * fix: use input_pipe_id to identify cli pipes instead of their message name * fix: come cleanups and add skip_cache parameter * fix: pipe/client-server communication robustness * fix: leaking messages between plugins while loading * feat: allow plugins to specify how a new plugin instance is launched when sending messages * fix: add permissions * refactor: adjust cli api * fix: improve cli plugin loading error messages * docs: cli pipe * fix: take plugin configuration into account when messaging between plugins * refactor: pipe message protobuf interface * refactor: update(event) -> pipe * refactor - rename CliMessage to CliPipe * fix: add is_private to pipes and change some naming * refactor - cli client * refactor: various cleanups * style(fmt): rustfmt * fix(pipes): backpressure across multiple plugins * style: some cleanups * style(fmt): rustfmt * style: fix merge conflict mistake * style(wording): clarify pipe permission * docs(changelog): introduce pipes * xtask: Disable pusing during publish (#3040) * xtask: Add `--no-push` flag to `publish` which can be used when simulating releases to work without a writable git fork of the zellij code. * xtask: Fix borrow issues * xtask/pipe: Require lockfile in publish to avoid errors from invalid dependency versions. * CHANGELOG: Add PR #3040. * fix(terminal): some real/saved cursor bugs during resize (#3032) * refactor: Simplify transfer_rows_from_viewport_to_lines_above next_lines is always consolidated to a single Row, which immediately gets removed - we can remove some dead code as a result * perf: Batch remove rows from the viewport for performance Given a 1MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~9s to ~3s * perf: Optimize Row::drain_until by splitting chars in one step Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~23s to ~20s * refactor: Simplify `if let` into a `.map` * refactor: There are only new saved coordinates when there were old ones * refactor: Unify viewport transfer: use common variable names * fix: Use same saved cursor logic in height resize as width See #2182 for original introduction that only added it in one branch, this fixes an issue where the saved cursor was incorrectly reset when the real cursor was * fix: Correct saved+real cursor calculations when reflowing long lines * fix: Don't create canonical lines if cursor ends on EOL after resize Previously if a 20 character line were split into two 10 character lines, the cursor would be placed on the line after the two lines. New characters would then be treated as a new canonical line. This commit fixes this by biasing cursors to the end of the previous line. * fix: for cursor index calculation in lines that are already wrapped * chore: test for real/saved cursor position being handled separately * chore: Apply cargo format * chore(repo): update issue templates * Bump rust version to 1.75.0 (#3039) * rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR #3039. * feat(plugins): introduce 'pipes', allowing users to pipe data to and control plugins from the command line (#3066) * prototype - working with message from the cli * prototype - pipe from the CLI to plugins * prototype - pipe from the CLI to plugins and back again * prototype - working with better cli interface * prototype - working after removing unused stuff * prototype - working with launching plugin if it is not launched, also fixed event ordering * refactor: change message to cli-message * prototype - allow plugins to send messages to each other * fix: allow cli messages to send plugin parameters (and implement backpressure) * fix: use input_pipe_id to identify cli pipes instead of their message name * fix: come cleanups and add skip_cache parameter * fix: pipe/client-server communication robustness * fix: leaking messages between plugins while loading * feat: allow plugins to specify how a new plugin instance is launched when sending messages * fix: add permissions * refactor: adjust cli api * fix: improve cli plugin loading error messages * docs: cli pipe * fix: take plugin configuration into account when messaging between plugins * refactor: pipe message protobuf interface * refactor: update(event) -> pipe * refactor - rename CliMessage to CliPipe * fix: add is_private to pipes and change some naming * refactor - cli client * refactor: various cleanups * style(fmt): rustfmt * fix(pipes): backpressure across multiple plugins * style: some cleanups * style(fmt): rustfmt * style: fix merge conflict mistake * style(wording): clarify pipe permission * docs(changelog): introduce pipes * fix: add some robustness and future proofing * fix e2e tests --------- Co-authored-by: Aram Drevekenin <aram@poor.dev> Co-authored-by: har7an <99636919+har7an@users.noreply.github.com> * fix integer overflow again (oops) --------- Co-authored-by: Aram Drevekenin <aram@poor.dev> Co-authored-by: har7an <99636919+har7an@users.noreply.github.com>

* rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR zellij-org#3039.

…3032) * refactor: Simplify transfer_rows_from_viewport_to_lines_above next_lines is always consolidated to a single Row, which immediately gets removed - we can remove some dead code as a result * perf: Batch remove rows from the viewport for performance Given a 1MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~9s to ~3s * perf: Optimize Row::drain_until by splitting chars in one step Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~23s to ~20s * refactor: Simplify `if let` into a `.map` * refactor: There are only new saved coordinates when there were old ones * refactor: Unify viewport transfer: use common variable names * fix: Use same saved cursor logic in height resize as width See zellij-org#2182 for original introduction that only added it in one branch, this fixes an issue where the saved cursor was incorrectly reset when the real cursor was * fix: Correct saved+real cursor calculations when reflowing long lines * fix: Don't create canonical lines if cursor ends on EOL after resize Previously if a 20 character line were split into two 10 character lines, the cursor would be placed on the line after the two lines. New characters would then be treated as a new canonical line. This commit fixes this by biasing cursors to the end of the previous line. * fix: for cursor index calculation in lines that are already wrapped * chore: test for real/saved cursor position being handled separately * chore: Apply cargo format * chore(repo): update issue templates * Bump rust version to 1.75.0 (zellij-org#3039) * rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR zellij-org#3039. * feat(plugins): introduce 'pipes', allowing users to pipe data to and control plugins from the command line (zellij-org#3066) * prototype - working with message from the cli * prototype - pipe from the CLI to plugins * prototype - pipe from the CLI to plugins and back again * prototype - working with better cli interface * prototype - working after removing unused stuff * prototype - working with launching plugin if it is not launched, also fixed event ordering * refactor: change message to cli-message * prototype - allow plugins to send messages to each other * fix: allow cli messages to send plugin parameters (and implement backpressure) * fix: use input_pipe_id to identify cli pipes instead of their message name * fix: come cleanups and add skip_cache parameter * fix: pipe/client-server communication robustness * fix: leaking messages between plugins while loading * feat: allow plugins to specify how a new plugin instance is launched when sending messages * fix: add permissions * refactor: adjust cli api * fix: improve cli plugin loading error messages * docs: cli pipe * fix: take plugin configuration into account when messaging between plugins * refactor: pipe message protobuf interface * refactor: update(event) -> pipe * refactor - rename CliMessage to CliPipe * fix: add is_private to pipes and change some naming * refactor - cli client * refactor: various cleanups * style(fmt): rustfmt * fix(pipes): backpressure across multiple plugins * style: some cleanups * style(fmt): rustfmt * style: fix merge conflict mistake * style(wording): clarify pipe permission * docs(changelog): introduce pipes * fix: add some robustness and future proofing * fix e2e tests --------- Co-authored-by: Aram Drevekenin <aram@poor.dev> Co-authored-by: har7an <99636919+har7an@users.noreply.github.com>

… reducing size of TerminalCharacter (zellij-org#3043) * refactor: Simplify transfer_rows_from_viewport_to_lines_above next_lines is always consolidated to a single Row, which immediately gets removed - we can remove some dead code as a result * perf: Batch remove rows from the viewport for performance Given a 1MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~9s to ~3s * perf: Optimize Row::drain_until by splitting chars in one step Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~23s to ~20s * refactor: Simplify `if let` into a `.map` * refactor: There are only new saved coordinates when there were old ones * refactor: Unify viewport transfer: use common variable names * fix: Use same saved cursor logic in height resize as width See zellij-org#2182 for original introduction that only added it in one branch, this fixes an issue where the saved cursor was incorrectly reset when the real cursor was * fix: Correct saved+real cursor calculations when reflowing long lines * fix: Don't create canonical lines if cursor ends on EOL after resize Previously if a 20 character line were split into two 10 character lines, the cursor would be placed on the line after the two lines. New characters would then be treated as a new canonical line. This commit fixes this by biasing cursors to the end of the previous line. * fix: for cursor index calculation in lines that are already wrapped * chore: test for real/saved cursor position being handled separately * chore: Apply cargo format * refactor: Unify viewport transfer: transfer + cursor update together * perf: Reduce size of TerminalCharacter from 72 to 60 bytes With a 10MB single line catted into a fresh terminal, VmRSS goes from 964092 kB to 874020 kB (as reported by /proc/<pid>/status) before/after this patch Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~15s to ~12.5s * fix(build): Don't unconditionally rebuild zellij-utils * refactor: Remove Copy impl on TerminalCharacter * perf: Rc styles to reduce TerminalCharacter from 60 to 24 bytes With a 10MB single line catted into a fresh terminal, VmRSS goes from 845156 kB to 478396 kB (as reported by /proc/<pid>/status) before/after this patch Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~12.5s to ~7s * perf: Remove RcCharacterStyles::Default, allow enum niche optimisation This reduces TerminalCharacter from 24 to 16 bytes With a 10MB single line catted into a fresh terminal, VmRSS goes from 478396 kB to 398108 kB (as reported by /proc/<pid>/status) before/after this patch Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~7s to ~4.75s * docs: link anchor omission from reset_all is deliberate reset_all is only used from ansi params, and ansi params don't control link anchor * fix: Remove no-op on variable that gets immediately dropped * refactor: Simplify replace_character_at logic The original condition checked absolute_x_index was in bounds, then used the index to manipulate it. This is equivalent to getting a ref to the character at that position and manipulating directly * chore: Run xtask format * chore(repo): update issue templates * Bump rust version to 1.75.0 (zellij-org#3039) * rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR zellij-org#3039. * feat(plugins): introduce 'pipes', allowing users to pipe data to and control plugins from the command line (zellij-org#3066) * prototype - working with message from the cli * prototype - pipe from the CLI to plugins * prototype - pipe from the CLI to plugins and back again * prototype - working with better cli interface * prototype - working after removing unused stuff * prototype - working with launching plugin if it is not launched, also fixed event ordering * refactor: change message to cli-message * prototype - allow plugins to send messages to each other * fix: allow cli messages to send plugin parameters (and implement backpressure) * fix: use input_pipe_id to identify cli pipes instead of their message name * fix: come cleanups and add skip_cache parameter * fix: pipe/client-server communication robustness * fix: leaking messages between plugins while loading * feat: allow plugins to specify how a new plugin instance is launched when sending messages * fix: add permissions * refactor: adjust cli api * fix: improve cli plugin loading error messages * docs: cli pipe * fix: take plugin configuration into account when messaging between plugins * refactor: pipe message protobuf interface * refactor: update(event) -> pipe * refactor - rename CliMessage to CliPipe * fix: add is_private to pipes and change some naming * refactor - cli client * refactor: various cleanups * style(fmt): rustfmt * fix(pipes): backpressure across multiple plugins * style: some cleanups * style(fmt): rustfmt * style: fix merge conflict mistake * style(wording): clarify pipe permission * docs(changelog): introduce pipes * xtask: Disable pusing during publish (zellij-org#3040) * xtask: Add `--no-push` flag to `publish` which can be used when simulating releases to work without a writable git fork of the zellij code. * xtask: Fix borrow issues * xtask/pipe: Require lockfile in publish to avoid errors from invalid dependency versions. * CHANGELOG: Add PR zellij-org#3040. * fix(terminal): some real/saved cursor bugs during resize (zellij-org#3032) * refactor: Simplify transfer_rows_from_viewport_to_lines_above next_lines is always consolidated to a single Row, which immediately gets removed - we can remove some dead code as a result * perf: Batch remove rows from the viewport for performance Given a 1MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~9s to ~3s * perf: Optimize Row::drain_until by splitting chars in one step Given a 10MB line catted into the terminal, a toggle-fullscreen + toggle-fullscreen + close-pane + `run true` goes from ~23s to ~20s * refactor: Simplify `if let` into a `.map` * refactor: There are only new saved coordinates when there were old ones * refactor: Unify viewport transfer: use common variable names * fix: Use same saved cursor logic in height resize as width See zellij-org#2182 for original introduction that only added it in one branch, this fixes an issue where the saved cursor was incorrectly reset when the real cursor was * fix: Correct saved+real cursor calculations when reflowing long lines * fix: Don't create canonical lines if cursor ends on EOL after resize Previously if a 20 character line were split into two 10 character lines, the cursor would be placed on the line after the two lines. New characters would then be treated as a new canonical line. This commit fixes this by biasing cursors to the end of the previous line. * fix: for cursor index calculation in lines that are already wrapped * chore: test for real/saved cursor position being handled separately * chore: Apply cargo format * chore(repo): update issue templates * Bump rust version to 1.75.0 (zellij-org#3039) * rust-toolchain: Bump toolchain version to 1.69.0 which, compared to the previous 1.67.0, has the following impacts on `zellij`: - [Turn off debuginfo for build deps][2]: Increases build time (on my machine) from ~230 s in 1.67.0 to ~250 s now, *which is unexpected* This version also changes [handling of the `default-features` flag][3] when specifying dependencies in `Cargo.toml`. If a dependent crate requires `default-features = true` on a crate that is required as `default-features = false` further up the dependency tree, the `true` setting "wins". We only specify `default-features = false` for three crates total: - `names`: This is used only by us - `surf`: This is used only by us - `vte`: This is also required by `strip-ansi-escapes`, but that has `default-features = false` as well How this affects our transitive dependencies is unknown at this point. [2]: rust-lang/cargo#11252 [3]: rust-lang/cargo#11409 * rust-toolchain: Bump toolchain version to 1.70.0 which, compared to the previous 1.69.0, as the following impacts on `zellij`: 1. [Enable sparse registry checkout for crates.io by default][1] This drastically increases the time to first build on a fresh rust installation/a rust installation with a clean cargo registry cache. Previously it took about 75s to populate the deps/cache (with `cargo fetch --locked` and ~100 MBit/s network), whereas now the same process takes ~10 s. 2. [The `OnceCell` type is now part of std][2] In theory, this would allow us to cut a dependency from `zellij-utils`, but the `once_cell` crate is pulled in by another 16 deps, so there's no point in attempting it right now. Build times and binary sizes are unaffected by this change compared to the previous 1.69.0 toolchain. [1]: rust-lang/cargo#11791 [2]: https://doc.rust-lang.org/stable/std/cell/struct.OnceCell.html * rust-toolchain: Bump toolchain version to 1.75.0 which, compared to the previous 1.70.0, has the following impacts on `zellij`: 1. [cross-crate inlining][8] This should increase application performance, as functions can now be inlined across crates. 2. [`async fn` in traits][9] This would allow us to drop the `async_trait` dependency, but it is currently still required by 3 other dependencies. Build time in debug mode (on my own PC) is cut down from 256s to 189s (for a clean build). Build time in release mode is cut down from 473s to 391s (for a clean build). Binary sizes only change minimally (825 MB -> 807 MB in debug, 29 MB -> 30 MB in release). [8]: rust-lang/rust#116505 [9]: rust-lang/rust#115822 * chore: Apply rustfmt. * CHANGELOG: Add PR zellij-org#3039. * feat(plugins): introduce 'pipes', allowing users to pipe data to and control plugins from the command line (zellij-org#3066) * prototype - working with message from the cli * prototype - pipe from the CLI to plugins * prototype - pipe from the CLI to plugins and back again * prototype - working with better cli interface * prototype - working after removing unused stuff * prototype - working with launching plugin if it is not launched, also fixed event ordering * refactor: change message to cli-message * prototype - allow plugins to send messages to each other * fix: allow cli messages to send plugin parameters (and implement backpressure) * fix: use input_pipe_id to identify cli pipes instead of their message name * fix: come cleanups and add skip_cache parameter * fix: pipe/client-server communication robustness * fix: leaking messages between plugins while loading * feat: allow plugins to specify how a new plugin instance is launched when sending messages * fix: add permissions * refactor: adjust cli api * fix: improve cli plugin loading error messages * docs: cli pipe * fix: take plugin configuration into account when messaging between plugins * refactor: pipe message protobuf interface * refactor: update(event) -> pipe * refactor - rename CliMessage to CliPipe * fix: add is_private to pipes and change some naming * refactor - cli client * refactor: various cleanups * style(fmt): rustfmt * fix(pipes): backpressure across multiple plugins * style: some cleanups * style(fmt): rustfmt * style: fix merge conflict mistake * style(wording): clarify pipe permission * docs(changelog): introduce pipes * fix: add some robustness and future proofing * fix e2e tests --------- Co-authored-by: Aram Drevekenin <aram@poor.dev> Co-authored-by: har7an <99636919+har7an@users.noreply.github.com> * fix integer overflow again (oops) --------- Co-authored-by: Aram Drevekenin <aram@poor.dev> Co-authored-by: har7an <99636919+har7an@users.noreply.github.com>

Pkgsrc changes: * Adjust patches and cargo checksums to new versions. * For an external LLVM, set dependency of llvm >= 16, in accordance with the upstream changes. * Mark that on NetBSD we now need >= 9.0, so 8.x is no longer supported. * On NetBSD/sparc64 10.x, we now need GCC 12 to build the embedded LLVM, which is version 17; apparently GCC 10.4 or 10.5 mis-compiles it, resulting in an illegal instruction fault during the build. Ref. rust-lang/rust#117231 Upstream changes: Version 1.75.0 (2023-12-28) ========================== - [Stabilize `async fn` and return-position `impl Trait` in traits.] (rust-lang/rust#115822) - [Allow function pointer signatures containing `&mut T` in `const` contexts.] (rust-lang/rust#116015) - [Match `usize`/`isize` exhaustively with half-open ranges.] (rust-lang/rust#116692) - [Guarantee that `char` has the same size and alignment as `u32`.] (rust-lang/rust#116894) - [Document that the null pointer has the 0 address.] (rust-lang/rust#116988) - [Allow partially moved values in `match`.] (rust-lang/rust#103208) - [Add notes about non-compliant FP behavior on 32bit x86 targets.] (rust-lang/rust#113053) - [Stabilize ratified RISC-V target features.] (rust-lang/rust#116485) Compiler -------- - [Rework negative coherence to properly consider impls that only partly overlap.] (rust-lang/rust#112875) - [Bump `COINDUCTIVE_OVERLAP_IN_COHERENCE` to deny, and warn in dependencies.] (rust-lang/rust#116493) - [Consider alias bounds when computing liveness in NLL.] (rust-lang/rust#116733) - [Add the V (vector) extension to the `riscv64-linux-android` target spec.] (rust-lang/rust#116618) - [Automatically enable cross-crate inlining for small functions] (rust-lang/rust#116505) - Add several new tier 3 targets: - [`csky-unknown-linux-gnuabiv2hf`] (rust-lang/rust#117049) - [`i586-unknown-netbsd`] (rust-lang/rust#117170) - [`mipsel-unknown-netbsd`] (rust-lang/rust#117356) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Override `Waker::clone_from` to avoid cloning `Waker`s unnecessarily.] (rust-lang/rust#96979) - [Implement `BufRead` for `VecDeque<u8>`.] (rust-lang/rust#110604) - [Implement `FusedIterator` for `DecodeUtf16` when the inner iterator does.] (rust-lang/rust#110729) - [Implement `Not, Bit{And,Or}{,Assign}` for IP addresses.] (rust-lang/rust#113747) - [Implement `Default` for `ExitCode`.] (rust-lang/rust#114589) - [Guarantee representation of None in NPO] (rust-lang/rust#115333) - [Document when atomic loads are guaranteed read-only.] (rust-lang/rust#115577) - [Broaden the consequences of recursive TLS initialization.] (rust-lang/rust#116172) - [Windows: Support sub-millisecond sleep.] (rust-lang/rust#116461) - [Fix generic bound of `str::SplitInclusive`'s `DoubleEndedIterator` impl] (rust-lang/rust#100806) - [Fix exit status / wait status on non-Unix `cfg(unix)` platforms.] (rust-lang/rust#115108) Stabilized APIs --------------- - [`Atomic*::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicUsize.html#method.from_ptr) - [`FileTimes`] (https://doc.rust-lang.org/stable/std/fs/struct.FileTimes.html) - [`FileTimesExt`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTimesExt.html) - [`File::set_modified`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.set_modified) - [`File::set_times`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.set_times) - [`IpAddr::to_canonical`] (https://doc.rust-lang.org/stable/core/net/enum.IpAddr.html#method.to_canonical) - [`Ipv6Addr::to_canonical`] (https://doc.rust-lang.org/stable/core/net/struct.Ipv6Addr.html#method.to_canonical) - [`Option::as_slice`] (https://doc.rust-lang.org/stable/core/option/enum.Option.html#method.as_slice) - [`Option::as_mut_slice`] (https://doc.rust-lang.org/stable/core/option/enum.Option.html#method.as_mut_slice) - [`pointer::byte_add`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.byte_add) - [`pointer::byte_offset`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.byte_offset) - [`pointer::byte_offset_from`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.byte_offset_from) - [`pointer::byte_sub`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.byte_sub) - [`pointer::wrapping_byte_add`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.wrapping_byte_add) - [`pointer::wrapping_byte_offset`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.wrapping_byte_offset) - [`pointer::wrapping_byte_sub`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.wrapping_byte_sub) These APIs are now stable in const contexts: - [`Ipv6Addr::to_ipv4_mapped`] (https://doc.rust-lang.org/stable/core/net/struct.Ipv6Addr.html#method.to_ipv4_mapped) - [`MaybeUninit::assume_init_read`] (https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#method.assume_init_read) - [`MaybeUninit::zeroed`] (https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#method.zeroed) - [`mem::discriminant`] (https://doc.rust-lang.org/stable/core/mem/fn.discriminant.html) - [`mem::zeroed`] (https://doc.rust-lang.org/stable/core/mem/fn.zeroed.html) Cargo ----- - [Add new packages to `[workspace.members]` automatically.] (rust-lang/cargo#12779) - [Allow version-less `Cargo.toml` manifests.] (rust-lang/cargo#12786) - [Make browser links out of HTML file paths.] (rust-lang/cargo#12889) Rustdoc ------- - [Accept less invalid Rust in rustdoc.] (rust-lang/rust#117450) - [Document lack of object safety on affected traits.] (rust-lang/rust#113241) - [Hide `#[repr(transparent)]` if it isn't part of the public ABI.] (rust-lang/rust#115439) - [Show enum discriminant if it is a C-like variant.] (rust-lang/rust#116142) Compatibility Notes ------------------- - [FreeBSD targets now require at least version 12.] (rust-lang/rust#114521) - [Formally demote tier 2 MIPS targets to tier 3.] (rust-lang/rust#115238) - [Make misalignment a hard error in `const` contexts.] (rust-lang/rust#115524) - [Fix detecting references to packed unsized fields.] (rust-lang/rust#115583) - [Remove support for compiler plugins.] (rust-lang/rust#116412)

…sound, r=aliemjay Consider alias bounds when computing liveness in NLL (but this time sound hopefully) This is a revival of #116040, except removing the changes to opaque lifetime captures check to make sure that we're not triggering any unsoundness due to the lack of general existential regions and the currently-existing `ReErased` hack we use instead. r? `@aliemjay` -- I appreciate you pointing out the unsoundenss in the previous iteration of this PR, and I'd like to hear that you're happy with this iteration of this PR before this goes back into FCP :> Fixes #116794 as well --- (mostly copied from #116040 and reworked slightly) # Background Right now, liveness analysis in NLL is a bit simplistic. It simply walks through all of the regions of a type and marks them as being live at points. This is problematic in the case of aliases, since it requires that we mark **all** of the regions in their args[^1] as live, leading to bugs like #42940. In reality, we may be able to deduce that fewer regions are allowed to be present in the projected type (or "hidden type" for opaques) via item bounds or where clauses, and therefore ideally, we should be able to soundly require fewer regions to be live in the alias. For example: ```rust trait Captures<'a> {} impl<T> Captures<'_> for T {} fn capture<'o>(_: &'o mut ()) -> impl Sized + Captures<'o> + 'static {} fn test_two_mut(mut x: ()) { let _f1 = capture(&mut x); let _f2 = capture(&mut x); //~^ ERROR cannot borrow `x` as mutable more than once at a time } ``` In the example above, we should be able to deduce from the `'static` bound on `capture`'s opaque that even though `'o` is a captured region, it *can never* show up in the opaque's hidden type, and can soundly be ignored for liveness purposes. # The Fix We apply a simple version of RFC 1214's `OutlivesProjectionEnv` and `OutlivesProjectionTraitDef` rules to NLL's `make_all_regions_live` computation. Specifically, when we encounter an alias type, we: 1. Look for a unique outlives bound in the param-env or item bounds for that alias. If there is more than one unique region, bail, unless any of the outlives bound's regions is `'static`, and in that case, prefer `'static`. If we find such a unique region, we can mark that outlives region as live and skip walking through the args of the opaque. 2. Otherwise, walk through the alias's args recursively, as we do today. ## Limitation: Multiple choices This approach has some limitations. Firstly, since liveness doesn't use the same type-test logic as outlives bounds do, we can't really try several options when we're faced with a choice. If we encounter two unique outlives regions in the param-env or bounds, we simply fall back to walking the opaque via its args. I expect this to be mostly mitigated by the special treatment of `'static`, and can be fixed in a forwards-compatible by a more sophisticated analysis in the future. ## Limitation: Opaque hidden types Secondly, we do not employ any of these rules when considering whether the regions captured by a hidden type are valid. That causes this code (cc #42940) to fail: ```rust trait Captures<'a> {} impl<T> Captures<'_> for T {} fn a() -> impl Sized + 'static { b(&vec![]) } fn b<'o>(_: &'o Vec<i32>) -> impl Sized + Captures<'o> + 'static {} ``` We need to have existential regions to avoid [unsoundness](rust-lang/rust#116040 (comment)) when an opaque captures a region which is not represented in its own substs but which outlives a region that does. ## Read more Context: rust-lang/rust#115822 (comment) (for the liveness case) More context: rust-lang/rust#42940 (comment) (for the opaque capture case, which this does not fix) [^1]: except for bivariant region args in opaques, which will become less relevant when we move onto edition 2024 capture semantics for opaques.

rustbot assigned petrochenkov Sep 13, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Sep 13, 2023

This comment has been minimized.

Sign in to view

rust-cloud-vms bot force-pushed the stabilize-rpitit branch from 586951c to fa86106 Compare September 13, 2023 18:30

This comment has been minimized.

Sign in to view

rust-cloud-vms bot force-pushed the stabilize-rpitit branch from fa86106 to fc32ded Compare September 13, 2023 19:01

This comment has been minimized.

Sign in to view

rust-cloud-vms bot force-pushed the stabilize-rpitit branch from e2decb9 to ca4ca59 Compare September 13, 2023 20:10

lcnr mentioned this pull request Sep 13, 2023

Stabilize impl_trait_projections #115659

Merged

lcnr added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Sep 13, 2023

This comment was marked as off-topic.

Sign in to view

This comment was marked as resolved.

Sign in to view

rami3l mentioned this pull request Sep 14, 2023

Unclear compiler error when impl Trait return value captures non-'static argument #82171

Open

baloo mentioned this pull request Dec 14, 2023

async-signature: move to AFIT RustCrypto/traits#1419

Closed

gendx mentioned this pull request Dec 21, 2023

Add a function to list tags to the FontTableProvider trait. yeslogic/allsorts#99

Closed

anatawa12 mentioned this pull request Dec 22, 2023

Refactors vrc-get/vrc-get#279

Merged

rubdos mentioned this pull request Dec 29, 2023

Rust 1.75.0 sailfishos/rust#22

Merged

w-utter mentioned this pull request Jan 1, 2024

Migrate to async traits for handling event callbacks webrtc-rs/webrtc#522

Open

tguichaoua mentioned this pull request Jan 11, 2024

Use async fn in trait instead of BoxedFuture bevyengine/bevy#11308

Closed

2e3s mentioned this pull request Jan 28, 2024

Doesn't compile 2e3s/awatcher#13

Closed

Qix- mentioned this pull request Jan 29, 2024

Feature-gate async_trait in lieu of new, standardized async_fn_in_trait feature. warp-tech/russh#236

Open

minghuaw mentioned this pull request Feb 18, 2024

Return impl Future + Send + ‘lifetime in traits instead of using async_trait macro minghuaw/fe2o3-amqp#220

Closed

traviscross mentioned this pull request Mar 18, 2024

Tracking Issue for Lifetime Capture Rules 2024 (RFC 3498) #117587

Open

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize `async fn` and return-position `impl Trait` in trait #115822

Stabilize `async fn` and return-position `impl Trait` in trait #115822

compiler-errors commented Sep 13, 2023 •

edited

rustbot commented Sep 13, 2023

rustbot commented Sep 13, 2023

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nikomatsakis commented Sep 13, 2023

withoutboats commented Sep 13, 2023 •

edited

workingjubilee commented Sep 13, 2023

nikomatsakis commented Sep 13, 2023 •

edited

oli-obk commented Sep 13, 2023 •

edited

This comment was marked as off-topic.

This comment was marked as resolved.

withoutboats commented Sep 13, 2023

A248 commented Sep 14, 2023

emersonford commented Sep 14, 2023 •

edited

Stabilize async fn and return-position impl Trait in trait #115822

Stabilize async fn and return-position impl Trait in trait #115822

Conversation

compiler-errors commented Sep 13, 2023 • edited

Stabilization report

Updates from thread

Stabilization Summary

Example of return-position impl Trait in trait definition

Example of return-position impl Trait in trait implementation

Example of async fn in trait

Motivation

async fn in trait

Return-position impl Trait in trait

Major design decisions

What is stabilized

Async functions in traits and trait implementations

Return-position impl trait in traits and trait implementations

Mixing async fn in trait and return-position impl Trait in trait

Return-position impl Trait in traits and trait implementations capture all in-scope lifetimes

Return-position impl Trait in traits are "always revealing"

Return-position impl Trait and async fn in traits are opted-out of object safety checks when the parent function has Self: Sized

What isn't stabilized (aka, potential future work)

Dynamic dispatch

Where-clause bounds on return-position impl Trait in traits or async futures (RTN/ART)

Require all futures to be Send

Avoid generics

Unify capture behavior for -> impl Trait in inherent methods and traits

impl_trait_projections

Tests

Remaining bugs and open issues

(Nightly) Return type notation bugs

Alternatives

Do nothing

Stabilize impl Trait in associated type instead

Use the old capture semantics for RPITIT

Make refinement a hard error

History

rustbot commented Sep 13, 2023

rustbot commented Sep 13, 2023

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nikomatsakis commented Sep 13, 2023

withoutboats commented Sep 13, 2023 • edited

workingjubilee commented Sep 13, 2023

nikomatsakis commented Sep 13, 2023 • edited

oli-obk commented Sep 13, 2023 • edited

This comment was marked as off-topic.

This comment was marked as resolved.

withoutboats commented Sep 13, 2023

A248 commented Sep 14, 2023

emersonford commented Sep 14, 2023 • edited

Stabilize `async fn` and return-position `impl Trait` in trait #115822

Stabilize `async fn` and return-position `impl Trait` in trait #115822

compiler-errors commented Sep 13, 2023 •

edited

Example of return-position `impl Trait` in trait definition

Example of return-position `impl Trait` in trait implementation

Example of `async fn` in trait

`async fn` in trait

Return-position `impl Trait` in trait

Mixing `async fn` in trait and return-position `impl Trait` in trait

Return-position `impl Trait` in traits and trait implementations capture all in-scope lifetimes

Return-position `impl Trait` in traits are "always revealing"

Return-position `impl Trait` and `async fn` in traits are opted-out of object safety checks when the parent function has `Self: Sized`

Where-clause bounds on return-position `impl Trait` in traits or async futures (RTN/ART)

Require all futures to be `Send`

Unify capture behavior for `-> impl Trait` in inherent methods and traits

`impl_trait_projections`

Stabilize `impl Trait` in associated type instead

withoutboats commented Sep 13, 2023 •

edited

nikomatsakis commented Sep 13, 2023 •

edited

oli-obk commented Sep 13, 2023 •

edited

emersonford commented Sep 14, 2023 •

edited