owned this note   changed 2 years ago  
Published Linked with GitHub

T-lang meeting agenda

  • Meeting date: 2023-01-31

Attendance

  • Team members: nikomatsakis, Josh, Scott, Felix, Tyler
  • Others: simulacrum

Meeting roles

  • Action item scribe: simulacrum
  • Note-taker: nikomatsakis

Scheduled meetings

  • Defer planning meeting until 2023-02-08 (Niko and Felix can't attend on the 1st)

Announcements or custom items

Planning meeting

  • Will hold planning meeting Feb 8
  • Please file your issue!

Governance draft

josh triplett: Draft Governance RFC has gone around [to all@rust-lang.org -ed.]. There have been updates, working to make it shorter. We're anticipating trying to make it public in the next few weeks, deferred to incorporate more feedback. Reach out to me or simulacrum or one of the others who sent out the mail to supply feedback.

Action item review

Pending lang team project proposals

None.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

PRs on the lang-team repo

None.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

RFCs waiting to be merged

None.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Proposed FCPs

Check your boxes!

"Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods" rfcs#3240

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

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

    • @Amanieu
    • @BurntSushi
    • @dtolnay
    • @joshtriplett
    • @m-ou-se
    • @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

"unsafe attributes" rfcs#3325

  • Link: https://github.com/rust-lang/rfcs/pull/3325
  • 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

"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

"Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063

"Tracking Issue for "C-unwind ABI", RFC 2945" rust#74990

  • Link: https://github.com/rust-lang/rust/issues/74990
  • 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:

    Shall we stabilize the extern "C-unwind" and other -unwind calling conventions? This change will leave extern "C" unchanged for now, but have the existing feature gate continue to opt into the new behavior on nightly. We'll do a separate change later to make extern "C" and similar not permit unwinding.

    @rfcbot merge

"Stabilise inline_const" rust#104087

tmandry: Just posted a comment to the thread about the fact that we don't error if there's a const eval error on an unused function, since the const blocks never get evaluated. I think we should error. But how do we make transition? This is existing behavior. Also a question of whether it should block inline const stabilization.

My recommendation is that we should add a lint and make it an error in the edition. I wouldn't block stabilization on it, but it is higher priority because of inline const.

joshtriplett: Can you clarify what you mean by not blocking?

tmandry: Don't have to wait for this lint to be implemented before stabilizing inline const.

joshtriplett: If we were proposing to do it as a lint, I'd agree, but I think it should just be an error. If we want it to be an error, I don't think we can reasonably do that later, it'd be a breaking change.

scottmcm: It's already a breaking change.

tmandry: Right, unless we limit it to inline const blocks, if that's even possible. That's why I advocated for changing behavior over an edition.

garyguo: I think there's two aspects of this. Dead code, and opt related. Oli has a PR to address the behavior in terms of "monomorphizing check mode" that does some of this. I think this should prob be in a design meeting with oli/ralf/me and other interested parties.

joshtriplett: +1, I think it suffices for this meeting to say that current behavior isn't in consensus on shipping

scottmcm: I like the point that making mono smarter or less smart is potentially a breaking change in the current rules. Moving towards a world where we can't accidentally break code because we monomorphized more makes sense to me. Lint that we start doing seems entirely reasonable.

garyguo: Not sure if it's breaking, since we do have the stable "link dead code" option, might be something we can do with a crater run.

nikomatsakis: who will file design meeting?

tmandry: could lump this in with the general post-monomorphization error meeting I intend to follow.

nikomatsakis: is it close enough that it makes sense to do together?

tmandry: maybe.

pnkfelix: comment you wrote in the issue says that, the fact that -C link-dead-code can cause an error– does it consistently cause an error in the example you gave?

tmandry: yes.

garyguo: eager mode fires an error, but lazy does not.

nikomatsakis: +1 to design meeting, prob 1 is enough.

tmandry: one is "post monomorphization errors" whereas this is really about functions that are unused and happen to use const. Not really monomorphization specific.

garyguo: From compiler perspective, tied to monomorphization.

tmandry: right, in compiler, we use monomorphization for dead code even without generics.

pnkfelix: we have to be careful, we want to permit working backwards from main and not forcing us to search all the code for potential errors.

joshtriplett: we need a clear statement then to define our expectation for reachability.

"Relax ordering rules for asm! operands" rust#105798

  • Link: https://github.com/rust-lang/rust/pull/105798
  • 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:

    Sorry for the delay in reviewing. This looks great! I think this technically needs an FCP (since it changes the stable interface), but I don't expect it to be a controversial one at all.

    @rfcbot merge

"Properly allow macro expanded format_args invocations to uses captures" rust#106505

concern potentially resolved!

Active FCPs

None.

P-critical issues

None.

Nominated RFCs, PRs and issues discussed this meeting

"Stabilise inline_const" rust#104087

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

Defer to design meeting.

"Mark RFC 1201 (naked functions) superseded by RFC 2972 (constrained naked functions)" rfcs#3223

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

scottmcm to author suggestion then merge.

"The #[diagnostic] attribute namespace" rfcs#3368

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

scottmcm: design meeting?

joshtriplett: not yet. recently reworked. let's discuss if we're comfortable with this namespace. by a week and a day from now, we'll prob be ready to schedule a design meeting, so let's ask them if they'd like to.

I think a lot of this has basically been pitched. The premise is very much "we still review individual proposals for attributes, this is just trying to handle forward compatibility reasonably".

I propose: folks read the RFC and decide if it does what they want it to do, and only use a design meeting if we're not in agreement.

"Implement a lint for implicit autoref of raw pointer dereference " rust#103735

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

scottmcm: I commented I was going to unnominate but hadn't, so skip this.

"Allow only implementing Read::read_buf" rust#106643

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

joshtriplett: Un-nominated since we are waiting on a draft. Somebody filed a tracking issue with a detailed description of the behavior.

scottmcm: I'm confused about use case.

joshtriplett: Specific use case is that people want to stabilize read_buf and require people to implement either read or read-buf but not both.

The issue right now is not if we want to stabilize "must implemented one of". The question ins: how much do we want to see happen before we let anybody stabilize read_buf such that there's a dependence on something like this in the stdlib?

scottmcm: A few years ago we had a problem where something got stabilized thanks to library. I think we need a reference PR before we can stabilize first method using this.

nikomatsakis: Reference PR for what? Not stabilizing the attribute what. We're stabilizing, in effect, a special rule for the read trait?

joshtriplett: I get the point that if we are stabilizing something that depends on it – sounds like you're saying you're fine to apply it in nightly, but you want to block stabilizing.

nikomatsakis: Just saying that we don't normally document unstable things, so we would normally document this as a special behavior of the Read trait.

scottmcm: Yes, this is a visible thing that ought to have something documented, like the const thing we did some time back (but unfortunately didn't document).

pnkfelix: Have to make sure that every trait that uses the attribute documents that behavior, right?

nikoamtsakis: Yes. May be worth adding some note to the reference that "some traits have this behavior"

pnkfelix: Not convinced that's useful, most important thing is to document it on the trait.

scottmcm: something about stability that Niko didn't catch

joshtriplett: Any objection to adding this to nightly now? All objections are related to stabilization, correct?

nikomatsakis: I am happy with the tracking issue which was created, it follows our experimental procedure.

scottmcm: correct. I'll add a note to the tracking issue for read-buf to note that we want to consider this before stabilizing.

nikomatsakis: side note that this situation comes up regularly and would be a nice language feature.

"Discuss subteam calendars" lang-team#192

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

joshtriplett: Style team has a calendar. Some subteam meetings show up on t-lang, some have their own. How do we want to handle this? I think it makes sense to say "no subteam meetings appear on t-lang" and have links from the same place for each subteam…?

nikomatsakis: I'm in camp "fewer calendars", as people have trouble finding the ones that exist…

joshtriplett: …but other people aren't aware of those meetings…

pnkfelix: …I think T-compiler has just one.

tmandry: I can relate to wanting some but not all events on my calendar.

joshtriplett: Yes, I wish there were better tools for having all calendars.

tmandry: the only way to get other people to know I am busy is to put me on the invite. Doesn't solve that problem.

nikomatsakis: what other subteams do we have?

joshtriplett: types, opsem, style…?

nikomatsakis: I don't care much, but we should at LEAST have a link with the calendars in use by each team.

pnkfelix: would be great to have it be part of the teams repo.

all: yes.

"Introduce terminating scope for tail expressions of breakable scopes" rust#106493

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

nikomatsakis: general problem being addressed is…

let f = something().bar(); // where bar is `&self`
//      ^^^^^^^^^^^ creates a temporary
  • this temporary is freed at end of the innermost statement
    • actually a simplification, there are other scopes –
  • unless it is assigned directly into a local variable, according to various rules
    • let f = &something()
      • something() is a temporary, but because it is clearly assigned into f, we extend that to the end of the enclosing block

Interesting twist:

{
    statement1;
    statement2;
    tail_expression // <-- 
}

temporary scope in the tail-expression is the same as the temporary scope of the block itself

let x = &{
    something() // <-- also create a temporary dropped at the end of the block
};

I think this was probably a mistake, but it is what we do now.

Docs on these rules.

I'm worried because there can be really subtle bugs for effectful destructors. Classic bug I'd like to see addressed is this:

match foo().lock().bar {
    // ^^^^^^^^^^^ dropped at end of statement
    ...
    arm => {
        foo().lock().baz += 1; // deadlock
    }
    ...
}

but that's independent from this PR.

Conclusion: this PR changes because of breakable scopes.

True best path: we should address these rules for the edition.

nikomatsakis: I can at least ping the PR author and see if they're willing to pursue a rationalization here for edition.

"make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias" rust#106180

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

discussion wherein we read the comments

Conclusion: jakob-degen's comment here indicates that this is compiler, in that the idea is to stop optimizing as aggressively because we the current optimization is not sound. It is not deciding language semantics or permissible unsafe code. Therefore, we are happy for the time being with the PR.

Some debate about what our general policy should be. Niko advocates for 'reliable first', de-optimize until we know when we can, but there is some concern about unsafe code authors relying on the LLVM attributes we emit not to change. This case is specific to Unpin and so affects primarily async + code like Rust For Linux.

"Tracking issue for deprecation lint proc_macro_derive_resolution_fallback" rust#83583

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

pnkfelix: I filed design mtg proposal for this, and removed the I-lang-nominated label. no need to discuss in mtg.

Nominated RFCs, PRs and issues NOT discussed this meeting

"RFC: Start working on a Rust specification" rfcs#3355

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

"inline_const does not evaluate in unused function" rust#106617

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

Select a repo