Try   HackMD

T-lang meeting agenda

  • Meeting date: 2023-07-11

Attendance

  • Team members: tmandry, Josh, scottmcm, pnkfelix
  • Others: Lokathor, TC

Meeting roles

  • Action item scribe:
  • Note-taker: pnkfelix

Scheduled meetings

  • (none currently)

Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.

Announcements or custom items

(Meeting attendees, feel free to add items here!)

Diffs on TAIT (TC)

Have an update on what we've learned since the design meeting.

TC: what is appetite from meeting participants for how much to dig in?
Josh: Lets aim for 3-4 minutes for the updates. If there's decisions, we'll do them async (or schedule further time)

TC: subjects: (see below), naming types that cannot be named, naming closures/futures, naming rpit return types
TC: we've found some feedback and use cases that differ from the above
TC: one, syntatic abstraction (see below)
TC: another, hiding types that can be named (see below). Different kinds of HW they compile for. Any specific target needs to get only one definition, but outside of the module, want clients to only be able to use methods that are public. Obvious question: Why not newtype pattern? Response: Yeah, we could have done that. Another note: The hide/expose pattern. (See below.)
TC: embedded statics (see below). There's bias in how people are using TAIT today. People who can use dyn Trait today are doing so; no reason to leverage an unstable feature. Its the people who cannot use dyn Trait that are resorting to TAIT. There are two different patterns that TC suggested to this user.
TC: basically, we've been responding to feedback in order to determine if what we're looking to stabilize is expressive enough.
TC: future possibilities not discussed in our meeting:
TC: cycle errors and how that affects things; after detailed discussion, determined that the cycle errors are not fundamental. They are something we can deal with as an implementation artifact, not a language design issue.
TC: for the HW thing, could allow constraining outside of the module. (This would be a way to allow people to bypass the signature restriction.)
TC: another future possibilty: an inverted rule for #[defines] that would allow a function to specify what it does not constrain. The advantage of doing it the other way around is that with #[defines] you need to support paths denoting types/liftimes/generic parameters in the attributes. But the inverted rule does not need to specify any paths in the attribute.
TC: re allowing generic parameters to be used generically (see below).
TC: and of course, diagnostics + error messages + heuristics are important; we have ideas to move on there.

Naming types that cannot be named – what the RFCs had in mind

The RFCs were trying to solve two main problems. Both of these relate to naming types that cannot be named, e.g. so that they can be used in APIs.

Naming closures and futures

Futures and closures can't be named in Rust today. The RFCs want to solve that.

pub type Fut = impl Future<Output = ()> + Send;
fn make_fut() -> Fut { async {} }
Naming RPIT return types

Using RPIT in an API today is an anti-pattern because it's annoying for your callers since they can't name the type, which means e.g. they can't put it in a struct unboxed. The RFCs want to solve that:

// Instead of RPIT, we can say:
pub type Iter = impl Iterator<Item = ()>;
fn make_iter() -> Iter { todo!() }

Feedback on other use-cases

Syntactic abstraction

When some people hear about this feature, they get excited because they want a kind of syntactic alias to reduce duplication. For code like this:

fn foo() -> impl Iterator<Item = impl Future<Item = impl Iterator<Item = ()>>> { todo!() }
fn bar() -> impl Iterator<Item = impl Future<Item = impl Iterator<Item = ()>>> { todo!() }
fn baz() -> impl Iterator<Item = impl Future<Item = impl Iterator<Item = ()>>> { todo!() }

They want to replace it with something shorter that means the same thing. @Lokathor is one person who has mentioned this. TAIT does not do this.

scottmcm: Ah, yes, the "is type alias macro-like or not" question from the RFC discussion.

scottmcm: If we had trait aliases (more like bound aliasses?) as stable, could this be done with those?

Hiding types that can be named

One user has a use-case that looks like this:

mod hw {
    #[cfg(target = "dev1")]
    pub type NetworkAdapter = NetworkAdapterDev1;
    #[cfg(target = "dev2")]
    pub type NetworkAdapter = NetworkAdapterDev2;

    mod drivers {
        mod network_adapter_dev1 {
            struct NetworkAdapterDev1;
            // ...
        }
        mod network_adapter_dev2 {
            struct NetworkAdapterDev2;
            // ...
        }
        // Other drivers that may need to use the NetworkAdapterDevX types.
    }

    fn initialize1() {
        #[cfg(target = "dev1")]
        {
            // Code that uses NetworkAdapterDev1 methods.
        }
        #[cfg(target = "dev2")]
        {
            // Code that uses NetworkAdapterDev2 methods.
        }
    }
    // Other code that does things like initialize1 does.
    // ...

    fn takes_network_adapter(adapter: NetworkAdapter) {
        #[cfg(target = "dev1")]
        {
            // Code that uses NetworkAdapterDev1 methods.
        }
        #[cfg(target = "dev2")]
        {
            // Code that uses NetworkAdapterDev2 methods.
        }
    }
}

// Code outside of the `hw` module uses NetworkAdapter but
// should only use methods shared by all adapters.

The code does not use TAIT now and it works without TAIT. The code does not enforce that code outside of the module can only use methods shared by all network adapters.

The user was hoping to use TAIT to solve this problem.

The problem can be solved with newtype pattern

One way to solve this problem does not involve using TAIT or traits at all. What the user hopes to accomplish can be done with a newtype and trait forwarding impls.

TAIT can be used without reorganizing the modules

For any case where the hidden type can be named, we can write something that simply hides and reveals the hidden type. This can be made elegant with the builder pattern.

Module hide/expose pattern
#![feature(type_alias_impl_trait)]
fn is_send<T: Send>(_t: &T) {}

pub use self::hidden::Opaque;
struct Concrete;

mod hidden {
    use super::Concrete;
    pub type Opaque = impl Sized;
    pub(super) fn into_opaque(x: Concrete) -> Opaque { x }
    pub(super) fn from_opaque(x: Opaque) -> Concrete { x as Concrete }
}

pub fn init() -> Opaque {
    hidden::into_opaque(Concrete)
}

pub fn frob(x: Opaque) -> Opaque {
    is_send(&x); // No cycle errors.
    let x: Concrete = hidden::from_opaque(x);
    hidden::into_opaque(x)
}

Embedded statics

Some users are using TAIT in embedded situations with mutable statics. In these cases, it's possible to need to think about the signature restriction.

Static pattern 1 (where bounds)
#![feature(type_alias_impl_trait)]

use core::any::Any;
use core::future::Future;

type Fut1 = Option<impl Future<Output = ()>>;
type Fut2 = Option<impl Future<Output = ()>>;
static mut FUT1: Fut1 = None;
static mut FUT2: Fut2 = None;
unsafe fn initialize_statics()
where
    Fut1: Any,
    Fut2: Any,
{
    FUT1 = Some(async {});
    FUT2 = Some(async {});
}
Static pattern 2 (constraining through encapsulation)
#![feature(type_alias_impl_trait)]

use core::future::Future;

type Fut1 = impl Future<Output = ()>;
type Fut2 = impl Future<Output = ()>;
struct Futs {
    fut1: Fut1,
    fut2: Fut2,
}
static mut FUTS: Option<Futs> = None;
fn make_statics() -> Futs {
    Futs { fut1: async {}, fut2: async {} }
}
unsafe fn initialize_statics() {
    unsafe { FUTS = Some(make_statics()) };
}

Future possibilities

Eliminating cycle errors

We have a plan to eliminate cycle errors. It cannot be done immediately and we'd prefer not to block stabilization on this. But they're not fundamental and can be solved in the future.

Allowing constraining outside of module
mod taits {
    pub type Foo = impl Future<Output = ()>;
}

fn make_foo() -> taits::Foo
where
    taits::Foo: IsConstrained
{ todo!() }
Inverted rule
type Foo = impl Future<Output = ()>;
fn make_foo() -> Foo { todo!() }

#[constrains_nothing]
fn uses_foo(x: Foo) {
    is_send(x); // No cycle errors.
}
Allowing generic parameters to be used non-generically

The proposal does not allow this:

type Foo<T> = impl Sized;
fn foo16() -> Foo<u16> { 0f32 }

We've since defined how this could be done.

process for experiments

scottmcm: What level of approval do we need to do to have an experiment following https://lang-team.rust-lang.org/how_to/experiment.html?
https://github.com/rust-lang/rust/pull/113522#issuecomment-1628634092

scott: I said I would second an experiment. Is that sufficient?
felix: in compiler source code?
scott: yes
tyler: needs a second, and then a ten day FCP type period.
felix: specifically waiting objections.
josh: We have a wide consensus in the lang team that a second and no objections is sufficient for an experiment.
josh: the question is where do we record that and provide a place for people to surface objections
josh: a random zulip comment does not sound sufficient.
josh: something that would show up in an meeting agenda seems better.
josh: helping the contributor through the MCP process seems good.
scott: okay so I can open an issue and then have a fast-tracked FCP?
josh: no I don't think an FCP is necessary here.
josh: just want a place to record the second and record the lack of objections.
felix: an obvious issue with T-compiler MCP process is that objections that are registred via zulip are not necessarily reflected in the github issue
josh: sure. but we don't need to block progress on more infrastructure. we can just file an MCP and let people who object actually file it on github
tyler: I think an option would be to make an FCP and then just check all the boxes, and then let people file objects via rfcbot.
scott: so should we do that?
josh: tooling here is only barely helping us. Lets focus on the main objective, which is to file an issue where we can officially track this.
scott: okay I'll ask them to open an issue on the lang-team repo and follow through there.

Lang weighing in on cargo script, cargo editions, and manifest embedding

Ongoing discussions about the format for embedding Cargo manifests in single-file cargo scripts. Want to make sure lang folks participate in that to the extent they want to.

New proposal for handling edition: always warn if not specified, but go ahead and run with latest edition for convenience of quick local hacks. Potentially avoids the problem of invalidating the purpose of editions.

josh: notably the issue is that just blindly using latest edition with no feedback will essentially break the intent of the edition mechanism
tyler: where is this conversation happening?
josh: T-lang zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Embedding.20cargo.20manifests.20in.20rust.20source
josh: and there's also a thread in T-cargo zulip
lokathor: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/cargo.20script.20and.20edition
lokathor: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/cargo.20script.20and.20manifests

instruction_set attribute updated per previous meeting (lokathor)

lokathor: amanieu had advised "say as little as possible about the exact effects to maximize future compiler flexibility." So now its ready to go.
josh: Attempted to start an FCP, not sure if rfcbot runs on this repo.
tyler: is the function pointer thing baked into the architecture?
lokathor: yes, that's how the CPU responds to an address

triagebot experimental support for new process

https://rust-lang.zulipchat.com/#narrow/stream/224082-triagebot/topic/Implementing.20new.20decision-making.20triagebot.20process

josh: volunteer who was enhancing triagebot state-machine has a decent first prototype. It is worth looking at the documentation in that pull request. Its not yet to the point where we can play with it on a rust repo but we're getting there.

Action item review

Pending lang team project proposals

None.

PRs on the lang-team repo

"Expand variadic generics design notes" lang-team#212

Link: https://github.com/rust-lang/lang-team/pull/212

josh: just raising attention, might not need discussion.
tyler: do we just accept design notes?
josh: its intended to reflect actual discussion that was had.
josh: i'm looking and I'm wondering if this is moving into the RFC territory. i.e. its someone who has a draft proposal mentioning their draft proposal in detail.
all: oh wait, this is a patch that isn't being presented as a diff because it also renames the file.
josh/scott: we should maybe ask them to not rename the file in the same commit that changes its content to make it easier to review.
scott/felix: oh wait that's already in a separate commit

"Frequently requested changes: return expr if condition" lang-team#213

Link: https://github.com/rust-lang/lang-team/pull/213

josh: similar just raising attention.

RFCs waiting to be merged

None.

S-waiting-on-team

"Tracking issue for dyn upcasting coercion" rust#65991

Link: https://github.com/rust-lang/rust/issues/65991

josh: Blocked waiting on Niko

"feat: split unsafe_code lint into lint group" rust#108975

Link: https://github.com/rust-lang/rust/pull/108975

josh: is this incorrectly labelled? Is it indeed waiting-on-team?
scott: Ralf has a comment that points out an oddity that this isn't just focused on discharging unsafe obligations (namely that deny(unsafe) flags declarations of unsafe trait)
josh/lokathor: agreed. But a different PR can be filed to address that. It doesn't change the fact that we should still move forward with closing this as the FCP is now complete.
josh: okay I'm closing this issue if no one objects
(no one objects)

"Create unnecessary_send_constraint lint for &(dyn ... + Send)" rust#110961

Link: https://github.com/rust-lang/rust/pull/110961

josh: this went through an FCP. there have been comments raised in the interim, but those can be handled async.
scott: we should unnominate (and remove S-waiting-on-team). Those labels are out-of-date.

"Support interpolated block for try and async" rust#112953

Link: https://github.com/rust-lang/rust/pull/112953

scott: if try and async work like this, then it makes sense to me that unsafe should work like this as well.
(some discussion revisiting question of why on earth this didn't work for unsafe in the first place)

Proposed FCPs

"Uplift clippy::option_env_unwrap lint" #111738

This issue proposes to make option_env!(..).unwrap() into a warn-by-default lint.

We had originally started an FCP to close this issue on the basis that it did not meet the bar for a rustc lint because we do not uplift lints that suggest only "maybe you could write this in a better way".

However, further input suggested that maybe it did meet the bar because it was suggested that option_env!(..).unwrap() is always an error, so we should make it a compilation error instead. On that basis, a concern was raised blocking the FCP close.

On a triage call with a small number of attendees, on this same basis we decided to start an FCP merge.

After that, however, a number of people showed up in the thread to point out that if cond { option_env!(..).unwrap() } is not always an error because the None.unwrap() may exist in a branch that is not taken. Some real use-cases have been provided for this.

As a more general point, option_env!(..) always might produce a None that the compiler could reason about at compilation time. It does seem a bit aggressive, given the nature of this macro, to suggest that someone may never want to panic! on this None value.

On this basis, I propose that we cancel the FCP merge and start an FCP close.

(some discussion followed)
pnkfelix: what is this motivation from Urgau that the compilation-error is significantly better than the runtime error for build scripts?
(discussion, followed by a suggestion from pnkfelix that we add it as an allow-by-default lint and then turn it on when compiling build scripts.)
josh: there is a non-lang consideration here that we should be weighing. there's no cost to us in T-lang to say "lets add it as an allow-by-default lint", but that's not zero-cost for T-compiler.
josh: so maybe there's a new question we need to raise elsewhere about whether this would get maintenance support.

scott: re the question of "its a shame that someone did the work"
scott: keep in mind that people can just file issues suggesting the uplift of a clippy lint; they don't need to do the work.

josh: so do we add this as allow-by-default with its false positives?
scott: I'm heavily biased against adding lints with false positives to rustc
tyler: yeah, we could push the question over to T-cargo to see if they want to push for this.
josh: Okay I'll leave a comment with an fcp close.

Check your boxes!

"unsafe attributes" rfcs#3325

"RFC: UTF-8 characters and escape codes in (byte) string literals" rfcs#3349

  • Link: https://github.com/rust-lang/rfcs/pull/3349
  • Tracking Comment:

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    I do think we should permit br"¥¥¥", but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.

    I'm going to go ahead and propose FCP for this. This does not preclude making further changes to how this information is presented.

    @rfcbot merge

    @rfcbot concern raw-byte-strings-with-unicode

"Stabilise inline_const" rust#104087

"Stabilize anonymous_lifetime_in_impl_trait" rust#107378

  • Link: https://github.com/rust-lang/rust/pull/107378
  • Tracking Comment:

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:

    @rfcbot merge

    We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.

"TAIT defining scope options" rust#107645

  • Link: https://github.com/rust-lang/rust/issues/107645
  • Tracking Comment:

    Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot fcp merge

    We held a design meeting yesterday where we reviewed this document prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.

    The document proposed the following resolution to this issue:

    • The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
      • Functions and methods must have the hidden type that they intend to constrain within their signature – within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
      • Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
      • A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
    • The hidden type may be constrained by functions, methods, constants, and statics.

    The doc goes into more detail about the justifications and alternatives.

    Given all this, I propose to merge and accept this proposal.

"Uplift clippy::option_env_unwrap lint" rust#111738

  • Link: https://github.com/rust-lang/rust/pull/111738
  • Tracking Comment:

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    Given that @nikomatsakis originally started the FCP to close, with the motivation "did not meet the rustc bar of preventing bugs", and given the point @Urgau made and @nikomatsakis supported that this is in fact catching something that's almost always a bug, I'm going to cancel the FCP to close, and start an FCP to merge to see if we have consensus in that direction.

    (Eagerly awaiting the rustbot or rfcbot functionality for tracking statuses by person and not predisposing in one direction or the other.)

    @rfcbot cancel
    @rfcbot merge

"make noop_method_call warn by default" rust#111916

  • Link: https://github.com/rust-lang/rust/pull/111916
  • Tracking Comment:

    Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot fcp merge

    From the random things I checked in the crater run, this looks like it'll be a great warning to have on-by-default.

"Support interpolated block for try and async" rust#112953

  • Link: https://github.com/rust-lang/rust/pull/112953
  • Tracking Comment:

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    We discussed this in today's @rust-lang/lang meeting. We were a little surprised this doesn't already work, and didn't see any reason it shouldn't work.

    @rust-lang/lang-advisors, are you aware of any reason that unsafe $block didn't work, historically?

    @rfcbot merge
    @rfcbot concern wait-for-advisors

"add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053

  • Link: https://github.com/rust-lang/rust/pull/113053
  • Tracking Comment:

    Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot fcp merge

    Here's what I wrote in zulip about why T-lang should merge this:

    my current take is: Its better for the docs to be updated to reflect reality, especially if its to point out a place where we are not conforming to an assumed specification. We can always change the docs later if we improve our conformance in some manner.

    At this point I'm not sure if we should force all such doc improvements to go through lang-team FCP, but its also safer to just do the FCP (and then let the team debate later if we want to follow less strict policy)

"Frequently requested changes: return expr if condition" lang-team#213

  • Link: https://github.com/rust-lang/lang-team/pull/213
  • Tracking Comment:

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot merge

Active FCPs

None.

P-critical issues

None.

Nominated RFCs, PRs and issues discussed this meeting

(none yet, move things from the section below as they are discussed)

Nominated RFCs, PRs and issues NOT discussed this meeting

"Explicit Tail Calls" rfcs#3407

Link: https://github.com/rust-lang/rfcs/pull/3407

"Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503

Link: https://github.com/rust-lang/rust/issues/54503

"dyn Trait comparison should not include the vtable pointer" rust#106447

Link: https://github.com/rust-lang/rust/issues/106447

"Make pointer_structural_match normal and warn" rust#110166

Link: https://github.com/rust-lang/rust/pull/110166

"Create unnecessary_send_constraint lint for &(dyn ... + Send)" rust#110961

Link: https://github.com/rust-lang/rust/pull/110961

"Shorten drop scope of temporaries in conditions" rust#111725

Link: https://github.com/rust-lang/rust/pull/111725

"Uplift clippy::option_env_unwrap lint" rust#111738

Link: https://github.com/rust-lang/rust/pull/111738

"feat: riscv-interrupt-{m,s} calling conventions" rust#111891

Link: https://github.com/rust-lang/rust/pull/111891

"let-else does not support else if" rust#111910

Link: https://github.com/rust-lang/rust/issues/111910

"make noop_method_call warn by default" rust#111916

Link: https://github.com/rust-lang/rust/pull/111916

"RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods" rust#112194

Link: https://github.com/rust-lang/rust/issues/112194

"add wrapping_offset_from which allows wrapping but still requires ptrs to be for the same allocation" rust#112837

Link: https://github.com/rust-lang/rust/pull/112837

"Report monomorphization time errors in dead code, too" rust#112879

Link: https://github.com/rust-lang/rust/pull/112879

"Support interpolated block for try and async" rust#112953

Link: https://github.com/rust-lang/rust/pull/112953

"add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053

Link: https://github.com/rust-lang/rust/pull/113053

"Support overriding warnings level for a specific lint via command line" rust#113307

Link: https://github.com/rust-lang/rust/pull/113307

"Rename and allow cast_ref_to_mut lint" rust#113422

Link: https://github.com/rust-lang/rust/pull/113422

"nightly regression: fnptrs with types containing () is warned to be not FFI-safe, while it is before" rust#113436

Link: https://github.com/rust-lang/rust/issues/113436

"Document soundness of Integer -> Pointer -> Integer conversions in const contexts." rust#113510

Link: https://github.com/rust-lang/rust/pull/113510

"Clearly specify the instruction_set inlining restrictions" reference#1307

Link: https://github.com/rust-lang/reference/pull/1307

"Does T-lang have opinion on floating-point guarantees?" lang-team#210

Link: https://github.com/rust-lang/lang-team/issues/210

Last changed by 
 
Rust Async Working Group
Rust Async Working Group
0
131

Read more

WG-async triage meeting 2024-10-03

Meeting date: 2024-10-03

Oct 3, 2024
WG-async triage meeting 2024-09-05

Meeting date: 2024-09-05

Sep 5, 2024
WG-async triage meeting 2024-08-08

Meeting date: 2024-08-08

Aug 8, 2024
Design meeting 2024-07-25: Open discussion

People:

Jul 25, 2024
Read more from Rust Async Working Group
Published on HackMD