Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
Joel Marcey: Following up on the Zulip discussion. I'm looking to figure out how we should pick the candidate for spec editor role. Subteam isn't formed yet. There's a chicken-and-egg problem.
joshtriplett: Seems like we should form the subteam. Does anyone in this room feel they need to be involved in selecting editor but not in the subsequent spec work? If not, shall we just make the subteam and have the subteam set requirements and interview?
nikomatsakis: Do we just need to move from the bullet points and make the decision?
joelmarcey: I've got some initial candidates and I'm at the point where we need to figure out the subteam.
joshtriplett: Given that we signed off on the original RFC, we don't necessarily need a full team sign-off on their being a subteam. The question is who will the initial members be. Or at least who from our perspective.
nikomatsakis: I don't think we know that exactly as we don't have a list.
joshtriplett: Need someone from lang, opsem. Do we need someone from libs, given that we're not specifying the library yet? May want to add someone if they have interest in any case.
nikomatsakis: types team.
nikomatsakis: at some point I was tossing around this hackmd with a draft for how this might work.
joelmarcey: can I throw my hat in the ring?
nikomatsakis: does it make sense for you to be a decision maker for what goes into final spec?
joelmarcey: being part of the process, and because I have experience in spec authoring.
joshtriplett: shouldn't try to decide in this meeting.
nikomatsakis: Yeah, and to be clear, I'm not disputing anybody's right to anything, just clarifying what the expectations are of members basically. We should draw up some proposal offline and move forward. The other question is how you've integrated in the past with interviewing.
joshtriplett: we prob want to move quickly, draw up some rough requirements from subteam, and then have those be used to get pool of candidates and have some folks from team involved in interview process, if nothing else to ensure they are someone they can work with
joelmarcey: I have a job description that is a starting point.
joshtriplett: A draft seems like a great way to start a discussion.
joshtriplett: process for how we will make decision:
nikomatsakis: usual process is kind of drawing up initial slade of leads and letting team drive its own membership going forward. A PR with a charter on the lang-team repo, with FCP, should suffice given that we already had the spec RFC.
joshtriplett: PR should include how membership is maintained going forward (does team determine new people to add, does parent team decide new people to add?)
None.
Link: https://github.com/rust-lang/lang-team/pull/212
tmandry to merge.
return expr if condition" lang-team#213Link: https://github.com/rust-lang/lang-team/pull/213
in FCP. scott/pnkfelix have not checked your boxes.
None.
S-waiting-on-teamLink: https://github.com/rust-lang/rust/issues/65991
TC: Last week we discussed and agreed to proceed to an FCP this week if no data had been provided. @nikomatsakis had posted a request on the ticket for this data with instructions on how to collect it. Multiple people have now run this test and reported data here. Surveying the results, the cost seems to be around 0.5% - 2% (overall).
Points raised in discussion:
wgpu_core crate whose vtables grew from 20 to 32 bytes, an 80% increase).tmandry: I haven't seen anybody say that it's blocking or affecting their project.
nikomatsakis: I feel like this is a real problem that should be addressed but I don't really know the parameters – who needs it? For what? Is LTO ok?
One option:
joshtriplett: Anyone want to block stabilization waiting on an opt-out?
tmandry: My concern is that adopting it is a breaking change, but I'm fine with stabilizing and adding in parallel.
nikomatsakis: May be a moot point because charleslf is super fast but I can leave a comment that, based on the data we've gotten, we are happy to move forward. The numbers that are showed show that an opt-out may be useful.
joshtriplett: It would be helpful also to clarify what the data actually means.
nikomatsakis: yes, it's not going to make the crates 80% bigger, just some number of vtables.
unnecessary_send_constraint lint for &(dyn ... + Send)" rust#110961Link: https://github.com/rust-lang/rust/pull/110961
TC: The FCP to merge has finished. Perhaps it should be merged and the tag should be removed?
Done.
Link: https://github.com/rust-lang/rust/pull/113126
TC: @petrochenkov reports being ready to stabilize most of RFC 2145.
joshtriplett: We should start FCP
tmandry: first I've seen of this RFC…what's the plan?
nikomatsakis: went from rules that have false positives and annoying rules to more seantics analysis. Don't remember all the details anymore in terms of the most annoying cases.
joshtriplett: crater run found
Check your boxes!
Or pattern without allocating place" rust#111752Team 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.
Thanks for the summary, @cjgillot !
I think lowering short-circuiting operators as control flow makes good sense, and fits well with future potential for things like let chains or scoping for an
isoperator. This does suggest that if we ever allow overriding them then those overrides ought to work via control-flow as well, but I don't see that as blocking anything that we'd need. (For example, we could still lower the LHS to a call that returns anOption, and have the lowering work on thatOption.)@rfcbot merge
TC: @scottmcm proposed a FCP to merge last week.
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.
@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)
TC: There's an ongoing proposed FCP here. @RalfJung has asked recently if maybe we should just have a separate page for platform errata.
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:
change-syntax-to-drop-parenthesesresolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974maybe-make-this-part-of-next-editionresolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458690311- syntax-not-ideal (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974)
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.
@rfcbot merge
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:
- raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
- waiting-on-update-re-using-char-and-string-tables (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1503875165)
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.
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
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.
@rfcbot merge
thiscall calling convention" rust#42202Team member @petrochenkov has proposed to merge this. The next step is review by the rest of the tagged team members:
- @Aaron1011
- @cjgillot
- @compiler-errors
- @davidtwco
- @eddyb
- @estebank
- @jackh726
- @lcnr
- @matthewjasper
- @michaelwoerister
- @nagisa
- @oli-obk
- @petrochenkov
- @pnkfelix
- @wesleywiser
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.
@rfcbot fcp merge
Stabilization report: https://github.com/rust-lang/rust/issues/42202#issuecomment-1565207948
Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
- @cramertj
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
Concerns:
expectations-around-panics-in-inline-constresolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210- optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
post-monomorphization-errorsresolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779- should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
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.
Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
@rfcbot fcp merge
anonymous_lifetime_in_impl_trait" rust#107378Team 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:
- elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
- why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
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.
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.
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:
- encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
- nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
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.
@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.
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.
@rfcbot merge
noop_method_call warn by default" rust#111916Link: https://github.com/rust-lang/rust/pull/111916
TC: This has 4/5 boxes checked, no concerns.
return expr if condition" lang-team#213Link: https://github.com/rust-lang/lang-team/pull/213
None.
(none yet, move things from the section below as they are discussed)
instruction_set effects" reference#1307Link: https://github.com/rust-lang/reference/pull/1307
TC: This should enter FCP merge, and @rfcbot is asking someone to add a final-comment-period label.
done.
Link: https://github.com/rust-lang/rust/pull/113586
TC: Discussed under proposed FCPs.
joshtriplett: this is effectively what the style team was created for. This PR adds to the template for new tracking issues. We'll have to go back to the existing tracking issues and update them.
Lokathor: just incomplete to not have formatting.
joshtriplett: yes and if we ship without formatting it causes breakage when we do.
thiscall calling convention" rust#42202Link: https://github.com/rust-lang/rust/issues/42202
TC: This was discussed last week. We decided to do a poll to get t-lang sign-off. It has 5/5 boxes checked now. Maybe this should be unnominated?
Josh to unnominate.
riscv-interrupt-{m,s} calling conventions" rust#111891Link: https://github.com/rust-lang/rust/pull/111891
TC: @jackh726 is asking for t-lang to sign-off on adding a feature gate for two new calling conventions.
left comment, we're good with it.
warnings level for a specific lint via command line" rust#113307Link: https://github.com/rust-lang/rust/pull/113307
TC: This is in a t-compiler proposed FCP, but @jieyouxu has a specific question for t-lang.
nikomatsakis: Last time we talked about this, it was revealed that warnings doesn't do what I thought it did, which is "the set of things that are warn-by-default".
joshtriplett: We had a discussion a long time ago that the people who are doing #[deny(warnings)] want anything that would've been a warning to be an error, which isn't quite how it's implemented, what do people expect when they say allow-warnings?
tmandry: and things like cap-lints are an issue here too. I think in source code, the inner source should override, but the CLI should more or less override those.
nikomatsakis: you think CLI should override no matter where it appears in the source?
tmandry: that's my gut instinct.
joshtriplett: what do we do today?
nikomatsakis: I guess I think of the CLI as the "very root level", but I can see why that wouldn't be what you wanted.
We can't settle this right now.
() is warned to be not FFI-safe, while it is before" rust#113436Link: https://github.com/rust-lang/rust/issues/113436
unnominated
unconditional_recursion warning detect recursive drops" rust#113902Link: https://github.com/rust-lang/rust/pull/113902
fcp merge'd.
Link: https://github.com/rust-lang/rust/issues/54503
TC: Based on feedback from t-lang, @xFrednet created a list of use-cases and is seeking review from t-lang.
Link: https://github.com/rust-lang/rust/issues/106447
TC: The FCP to close this issue has been completed. However, @Amanieu is still looking for a way forward. There's been some discussion on Zulip about this.
Link: https://github.com/rust-lang/rfcs/pull/3336
TC: There's been considerable recent discussion of this over on Zulip.
cast_ref_to_mut lint" rust#113422Link: https://github.com/rust-lang/rust/pull/113422
TC: There's a feeling that this does not need a t-lang sign-off, but t-compiler wanted to check that t-lang agreed.
const contexts." rust#113510Link: https://github.com/rust-lang/rust/pull/113510
Link: https://github.com/rust-lang/rust/pull/112879
TC: This is a blocker for the stabilization of inline_const. We discussed this last week and decided we were OK with it. @tmandry posted a comment asking about a possible crater run.
Link: https://github.com/rust-lang/rust/issues/112194
TC: We'll be talking a lot about capture rules tomorrow.
Link: https://github.com/rust-lang/rfcs/pull/3407
TC: @WaffleLapkin has been working on an implementation.
else if" rust#111910Link: https://github.com/rust-lang/rust/issues/111910
TC: @lcnr wants to do this. It's waiting on a t-lang member to sponsor an experiment.
Link: https://github.com/rust-lang/rust/pull/110166
TC: This has completed its FCP merge, but it is waiting on the author for some final changes.
Or pattern without allocating place" rust#111752Link: https://github.com/rust-lang/rust/pull/111752
TC: Discussed under proposed FCPs.
noop_method_call warn by default" rust#111916Link: https://github.com/rust-lang/rust/pull/111916
TC: Discussed under proposed FCPs.
Link: https://github.com/rust-lang/rust/pull/113053
TC: Discussed under proposed FCPs.
Link: https://github.com/rust-lang/rust/pull/113126
TC: Discussed under waiting on team.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe