or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
T-lang meeting agenda
Attendance
Meeting roles
Scheduled meetings
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!)
Guest attendee items
TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular.
Moving right along
TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause.
Lang oversight on int->ptr, ptr->int casts?
scottmcm: RalfJ has asked whether lang wants oversight on the documentation about these casts.
scottmcm: My view is that we have an RFC about this and that T-opsem can proceed on the details about this without us.
scottmcm: "transmute: caution against int2ptr transmutation" https://github.com/rust-lang/rust/pull/122379
scottmcm: If anyone has objections to this, it'd be good to mention that now.
Consensus: T-opsem can proceed on making changes to documentation consistent with the RFC we approved without further checkboxes from us on that documentation.
Design meeting at 12:30 EST / 09:30 PST / 17:30 CET
TC: Remember that our design meetings start half an hour earlier than in the past. For Europeans, note that for all of this month, all of our meetings start an hour earlier where you are.
RTN
TC: We had a call 2024-03-04 to discuss the syntax of RTN. There was no explicit consensus from that meeting, but the general mood was that there were two axes along which we might find consensus:
()
or(..)
as sugar for::Output
.The next steps, per NM, are:
Rust 2024 review
Project board: https://github.com/orgs/rust-lang/projects/43/views/5
Tracking Issue for Lifetime Capture Rules 2024 (RFC 3498) #117587
Link: https://github.com/rust-lang/rust/issues/117587
TC: We accepted the RFC and the implementation has landed for Rust 2024. We do need to stabilize some way of expressing precise capturing. That probably means stabilizing TAIT. We're starting with stabilizing ATPIT.
TC: That stabilization now on track. We're finishing some final items and are hopeful this may go into FCP soon.
Reserve gen keyword in 2024 edition for Iterator generators #3513
Link: https://github.com/rust-lang/rfcs/pull/3513
TC: We've done two recent things on this RFC:
gen fn
to be a future possibility.gen
blocks to being an open question rather than a future possibility.TC: That last change should resolve the open concern, which when done will cause this to move into FCP.
We've done the first. We'll do the second (it's currently listed as a future possibility).
TC: As an addendum to the discussion last week, we had discussed the possibility of reserving the
yields
keyword forgen
closures, e.g.:TC: In discussion with Oli after the meeting, he pointed out that this is not needed, as even though this would appear in expressions, the keyword can and should be contextual because it's always appearing after
gen |..|
.Tracking issue for promoting
!
to a type (RFC 1216) #35121Link: https://github.com/rust-lang/rust/issues/35121
TC: We'll be discussing this in the design meeting today. Waffle has put together a document for us.
Nominated RFCs, PRs, and issues
"Fallout from expansion of redundant import checking" rust#121708
Link: https://github.com/rust-lang/rust/issues/121708
TC: tmandry nominates this for us:
TC: What do we think?
tmandry: I'm looking for a vibe check on how people would feel about some kind of policy that might prevent this kind of disruption.
pnkfelix: Your proposal here would include adding a new name for the expansion then including it in a lint group?
tmandry: Yes, that'd be fine.
scottmcm: I'd be worried about a policy that would require a new lint in all cases. It'd be good if these expansions always had a machine-applicable fix though.
tmandry: It could be OK to either have a machine-applicable fix or to use a new name.
Josh: Would be in favor of a policy of "we should not do all three of 1) making a lint we expect to flag large amounts of existing code, 2) putting it under an existing lint name such that it's not trivial to turn off independently, and 3) not having a machine-applicable fix".
scottmcm: What I'm wondering most about that is the degree to which that is already the policy or the degree to which people just didn't expect the amount of impact that this lint had.
tmandry: I don't think there's a policy here.
scottmcm: The problem is that it'd be bad to require a new lint for each expansion, and it would be bad to require crater for each change to a lint.
CE: My feeling is that compiler maintainers do have a sense of this and are cautious about it. We could have a policy that's not perfectly measurable.
waffle: +1.
pnkfelix: In my mind, there are two things. One is trying to prevent these before they hit master. Then there's what we do after it hits master and people start filing bugs. Those bugs may have been a hint that we need to do something here. I like the idea of having a policy in place, but perhaps we don't need to prevent these from hitting master. We could handle these after that based on feedback.
tmandry: There's a weird incentive here that expanding an existing lint requires less process than creating a new one.
scottmcm: Agreed on that.
tmandry: I'll put together a policy proposal here.
"align_offset, align_to: no longer allow implementations to spuriously fail to align" rust#121201
Link: https://github.com/rust-lang/rust/pull/121201
TC: RalfJ had nominated this question for us, but it proceeded without us getting to it in a meeting, so I highlight it here for visibility. RalfJ:
Josh:
RalfJ:
Josh:
RalfJ:
TC: This sounds OK to us?
scottmcm: People have complained about
align_to
's documented behavior for ages. So this fixes that. We can add a different function later if necessary.tmandry: Sounds good to me.
Consensus: We're OK with this having been merged and the consequences of that noted.
"Arbitrary self types v2" rfcs#3519
Link: https://github.com/rust-lang/rfcs/pull/3519
TC: We had a design meeting about this on 2024-02-28. The identified next step was to write up a list of the available options. That document is here:
https://hackmd.io/eXfrzrR7T1-3HVh6w5JMqA
The general mood in the meeting tended in the direction of doing the simpler thing for now (supporting only newtype wrappers) and saving space by giving a hard error on resolution ambiguity, but there were various concerns.
TC: I'm writing up a document to bring these together. So I may reach out to you to set up a call to be sure your views and concerns are faithfully represented.
TC: This came up in the RfL meeting also.
Josh: The RfL team thought that newtype wrappers would be OK for them. They also seemed cautiously positive about the
derive(SmartPointer)
idea that CE suggested, but would need to see the details.TC: It'll probably fall on us to write out a proposal for
derive(SmartPointer)
.CE: (Discusses details of
derive(SmartPointer)
.)Josh: It's appealing that our macro here could check the invariants.
"regression: encountered mutable pointer in final value" rust#121610
Link: https://github.com/rust-lang/rust/issues/121610
TC: We discussed this in the meeting on 2024-03-06 but were unclear about the situation, particularly as it pertained to a decision we had earlier made here:
https://github.com/rust-lang/rust/pull/119044
TC: RalfJ has now written up a document for us about this:
https://hackmd.io/3fj1WHGIT7-l8hRHxcKS8A
TC: And I've scheduled for him and Oli to appear in our 90 minute extended triage meeting next week.
"restrict promotion of
const fn
calls" rust#121557Link: https://github.com/rust-lang/rust/pull/121557
TC: RalfJ nominates this for us:
scottmcm: This is part of the continuing saga. If we had
const
blocks we probably wouldn't need to do this. But it looks likeRalfJ
has found another bit that we can fix.TC: We're blocked on
const
blocks by the check build regression.scottmcm: We could just skip it in check builds. We accepted an RFC that said that we're allowed to do that. https://rust-lang.github.io/rfcs/3477-cargo-check-lang-policy.html
TC: I'll run that by Oli.
tmandry: That wouldn't be the end of the world.
Josh: We'd have to be careful because people use consts for static assertions.
scottmcm: Those would still probably be fine because they're item-level consts.
gen
blockstmandry: On a bikeshed note. I'm having second thoughts about
gen
as a keyword. I'm curious what the RFC authors think about usinggenerator
.TC: As one of the authors, my feeling is that
gen
fits better in the language given e.g.mod
,fn
,async
, etc.Josh: I think the concept of a generator is familiar to people. I think that
generator
would feel excessively long for e.g. generator closures. I do wish we could call thisiter
. But we probably can't do that because it'll break half the universe.TC: The RFC authors also prefered
iter
but backed off of it for the reasons you mention.tmandry: I'll post in the issue about it, but it doesn't need to block acceptance.
"Implement
PartialOrd
andOrd
forDiscriminant
" rust#106418Link: https://github.com/rust-lang/rust/pull/106418
TC: This has been on and off our radar. @scottmcm in particular has strong concerns about this that he first raised 5 years ago.
scottmcm:
https://github.com/rust-lang/rust/pull/106418#pullrequestreview-1594299402
TC: Recently, T-libs-api decided to move forward on this:
TC: tmandry has filed a concern:
TC: (In addition to tmandry, this one probably needs scottmcm present to discuss.)
TC: What do we think?
scottmcm: I need to turn my sketch into a proposal. This proposal probably covers this as well as the other issue. This proposal may cover all of the reasons that people want
Ord
onDiscriminant
, which would obviate this issue.Josh: Please check back with the OP who proposed
PartialOrd
forDiscriminant
, to see if the proposed solution solves their problem. If it does, +1 for scott's solution, which looks quite elegant.pnkfelix: (The reminds me of this old issue, back when I put in exactly the (big ugly) codegen scott described: https://github.com/rust-lang/rust/pull/15503)
tmandry: I think I can resolve my concern on this issue.
scottmcm: I'll file a concern on the issue about his alternate proposal.
Consensus: We'll wait for seeing the details of scottmcm's proposal.
(The meeting ended here.)
"Support ?Trait bounds in supertraits and dyn Trait under a feature gate" rust#121676
Link: https://github.com/rust-lang/rust/pull/121676
TC: This is related to this MCP:
https://github.com/rust-lang/compiler-team/issues/727
TC: The question here is whether we want to charter this as an experiment.
"Initial support for auto traits with default bounds" rust#120706
Link: https://github.com/rust-lang/rust/pull/120706
TC: This is related to this MCP:
https://github.com/rust-lang/compiler-team/issues/727
TC: The question here is whether we want to charter this as an experiment.
"Add simple async drop glue generation" rust#121801
Link: https://github.com/rust-lang/rust/pull/121801
TC: This is related to this MCP:
https://github.com/rust-lang/compiler-team/issues/727
TC: The question here is whether we want to charter this as an experiment.
"Consider linting against 00B7 aka interpunct aka middle dot" rust#120797
Link: https://github.com/rust-lang/rust/issues/120797
TC: In the meeting on 2024-02-21 we proposed to postpone this.
TC: If others agree, this FCP can move forward.
"Tracking issue for function attribute
#[coverage]
" rust#84605Link: https://github.com/rust-lang/rust/issues/84605
TC: This is about stabilizing a
#[coverage(off)]
attribute to exclude items from-Z instrument-coverage
.Josh proposed FCP merge and nominated this for us.
There are two open questions about applying this automatically to nested functions and to inlined functions.
TC: What do we think?
"
is
operator for pattern-matching and binding" rfcs#3573Link: https://github.com/rust-lang/rfcs/pull/3573
TC: Josh proposes for us that we should accept:
And:
TC: The main topic discussed in the issue thread so far has been the degree to which Rust should have "two ways to do things". Probably the more interesting issue is how the binding and drop scopes for this should work.
TC: Earlier we discussed how we should prioritize stabilizing let chains, and tmandry suggested we may want to allow those to settle first.
TC: What do we think, as a gut check?
"Should Rust still ignore SIGPIPE by default?" rust#62569
Link: https://github.com/rust-lang/rust/issues/62569
TC: Prior to
main()
being executed, the Rust startup code makes a syscall to change the handling ofSIGPIPE
. Many believe that this is wrong thing for a low-level language like Rust to do, because 1) it makes it impossible to recover what the original value was, and 2) means things likeseccomp
filters must be adjusted for this.It's also just, in a practical sense, wrong for most CLI applications.
This seems to have been added back when Rust had green threads and then forgotten about. But it's been an ongoing footgun.
There was discussion in 2019 about fixing this over an edition, but nothing came of it.
TC: Are we interested in fixing it over this one?
"Stabilize
#[unix_sigpipe = "sig_dfl"]
onfn main()
" rust#120832Link: https://github.com/rust-lang/rust/pull/120832
TC: This is related to the above, and is a proposal to stabilize an option to have the startup code set
SIGPIPE
to the other handler. However, this does not address the problem that the Rust startup code is making this syscall at all, which means that e.g.seccomp
filters must be correctly adjusted and it's still impossible to recover the original inherited setting of this handler.There are also the following options to this attribute that are not proposed for stabilization here:
sig_ign
: This is the current default behavior.inherent
: This would prevent the startup code from making this syscall at all.TC: What do we think?
"offset: allow zero-byte offset on arbitrary pointers" rust#117329
Link: https://github.com/rust-lang/rust/pull/117329
TC: RalfJ nominates this for us:
TC: What do we think?
"Let's
#[expect]
some lints: Stabilizelint_reasons
(RFC 2383) " rust#120924Link: https://github.com/rust-lang/rust/pull/120924
TC: Since the last time this was proposed for stabilization, various unresolved questions have now been resolved, so this is being proposed again.
TC: What do we think?
"Lang discussion: Item-level
const {}
blocks, andconst { assert!(...) }
" lang-team#251Link: https://github.com/rust-lang/lang-team/issues/251
TC: This issue was raised due to discussion in a T-libs-api call. Josh gives the context:
CAD97 noted:
TC: What do we think?
"add float semantics RFC" rfcs#3514
Link: https://github.com/rust-lang/rfcs/pull/3514
TC: In addition to documenting the current behavior carefully, this RFC (per RalfJ)…
TC: What do we think? tmandry proposed this for FCP merge back in October 2023.
"Don't make statement nonterminals match pattern nonterminals" rust#120221
Link: https://github.com/rust-lang/rust/pull/120221
TC: CE handed this one to us, since it changes the contract of macro matchers:
TC: What do we think?
"RFC: Allow symbol re-export in cdylib crate from linked staticlib" rfcs#3556
Link: https://github.com/rust-lang/rfcs/pull/3556
TC: This seems to be about making the following work:
There are apparently use cases for this.
What's interesting is that apparently it already does, but we issue a warning that is wrong:
TC: One of the author's asks of us is that we don't make this into a hard error (e.g. with the new edition).
TC: What do we think?
"Tracking Issue for unicode and escape codes in literals" rust#116907
Link: https://github.com/rust-lang/rust/issues/116907
TC: nnethercote has implemented most of RFC 3349 ("Mixed UTF-8 literals") and, based on implementation experience, argues that the remainder of the RFC should not be implemented:
TC: What do we think?
"Better errors with bad/missing identifiers in MBEs" rust#118939
Link: https://github.com/rust-lang/rust/pull/118939
TC: The idea here seems to be to improve some diagnostics around
macro_rules
, but this seems to be done by way of reserving themacro_rules
token more widely, which is a breaking change. Petrochenkov has objected to it on that basis, given that reservingmacro_rules
minimally has been the intention since we hope it will one day disappear in favor ofmacro
. What do we think?"unsafe attributes" rfcs#3325
Link: https://github.com/rust-lang/rfcs/pull/3325
TC: tmandry nominated this one for us so that we could finish the bikeshed that we started in time for Rust 2024.
Lokathor laid out these options:
TC: This is an interesting case because we are not discharging unsafety, as with
unsafe { expr }
in a function body. Neither does sayingunsafe
here create and push upward a type-checked obligation. Instead, the upward obligation exists regardless and there is no means to signal to the compiler that it has been discharged and no enforcement of that.TC: Another option I've seen discussed is finding some way to make these annotations safe.
TC: What do we think?
TC: A poll was opened about this question here:
https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unsafe.20attribute.20syntax
TC: While obviously such voting is not dispositive, it is perhaps at least worth noting that sentiment was strongly in favor of
#[unsafe(no_mangle)]
."Add lint against function pointer comparisons" rust#118833
Link: https://github.com/rust-lang/rust/pull/118833
TC: In the 2024-01-03 call, we developed a tentative consensus to lint against direct function pointer comparison and to push people toward using
ptr::fn_addr_eq
. We decided to ask T-libs-api to add this. There's now an open proposal for that here:https://github.com/rust-lang/libs-team/issues/323
One question that has come up is whether we would expect this to work like
ptr::addr_eq
and have separate generic parameters, e.g.:Or whether we would prefer that
fn_addr_eq
enforced type equality of the function pointers. Since we're the ones asking for this, we probably want to develop a consensus here. We discussed this in the call on 2024-01-10, then we opened a Zulip thread:https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Signature.20of.20.60ptr.3A.3Afn_addr_eq.60
TC: On this subject, scottmcm raised this point, with which pnkfelix seemed to concur:
TC: scottmcm also asserted confidence that allowing mixed-type pointer comparisons is correct for
ptr::addr_eq
since comparing the addresses of*const T
,*const [T; N]
, and*const [T]
are all reasonable. I pointed out that, if that's reasonable, thenptr::fn_addr_eq
is the higher-ranked version of that, since for the same use cases, it could be reasonable to compare function pointers that return those three different things or accept them as arguments.TC: Adding to that, scottmcm noted that comparing addresses despite lifetime differences is also compelling, e.g. comparing
fn(Box<T>) -> &'static mut T
withfor<'a> fn(Box<T>) -> &'a mut T
.TC: Other alternatives we considered were not stabilizing
ptr::fn_addr_eq
at all and instead stabilizingFnPtr
so people could writeptr::addr_eq(fn1.addr(), fn2.addr())
, or expecting that people would write insteadfn1 as *const () == fn2 as *const ()
.TC: Recently CAD97 raised an interesting alternative:
TC: What do we think?
TC: Separately, on the 2024-01-10 call, we discussed some interest use cases for function pointer comparison, especially when it's indirected through
PartialEq
. We had earlier said we didn't want to lint when such comparisons were indirected through generics, but we did address the non-generic case of simply composing such comparisons.One example of how this is used is in the standard library, in
Waker::will_wake
:https://doc.rust-lang.org/core/task/struct.Waker.html#method.will_wake
It's comparing multiple function pointers via a
#[derive(PartialEq)]
on theRawWakerVTable
.We decided on 2024-01-01 that this case was interesting and we wanted to think about it further. We opened a discussion thread about this:
https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Function.20pointer.20comparison.20and.20.60PartialEq.60
Since then, another interesting use case in the standard library was raised, in the formatting machinery:
https://doc.rust-lang.org/src/core/fmt/rt.rs.html
What do we think about these, and would we lint on derived
PartialEq
cases like these or no?"RFC: Syntax for embedding cargo-script manifests" rfcs#3503
Link: https://github.com/rust-lang/rfcs/pull/3503
TC: This has been changed to use
---
syntax with an optional infostring (that is arbitrary except for forbidding whitespace and commas).TC: tmandry, Josh, and I are +1. What do we think?
"Uplift
clippy::invalid_null_ptr_usage
lint" rust#119220Link: https://github.com/rust-lang/rust/pull/119220
TC: Urgau proposes this for us:
TC: What do we think?
"#[cold] on match arms" rust#120193
Link: https://github.com/rust-lang/rust/pull/120193
TC: Apparently our unstable
likely
andunlikely
intrinsics don't work. There's a proposal to do some work on fixing that and stabilizing a solution here. The nominated question is whether we want to charter this as an experiment."
.await
does not perform autoref or autoderef" rust#111546Link: https://github.com/rust-lang/rust/issues/111546
TC: This was nominated for T-lang by WG-async. @tmandry said:
TC: There's now been a crater run done for this. The result was that this breaks a small number of crates, but at least one of those crates has a large number of dependents (
aws-smithy-runtime
). It can be fixed in the dependency in such a way that dependent crates do not have to make changes, but those dependent crates would need to update to a fixed version of the dependency.(See this discussion.)
TC: What do we think?
"Add
wasm_c_abi
future-incompat
lint" rust#117918Link: https://github.com/rust-lang/rust/pull/117918
TC: daxpedda gives the context:
TC: Is this something we want to do?
"types team / lang team interaction" rust#116557
Link: https://github.com/rust-lang/rust/issues/116557
TC: nikomatsakis nominated this:
TC: What do we think?
"Uplift
clippy::precedence
lint" rust#117161Link: https://github.com/rust-lang/rust/pull/117161
TC: The proposal is to lint against:
These would instead be written:
Prompts for discussion:
rustc
?!
,*
,&
)?"Raw Keywords" rfcs#3098
Link: https://github.com/rust-lang/rfcs/pull/3098
"Tracking issue for RFC 2102, "Unnamed fields of struct and union type"" rust#49804
Link: https://github.com/rust-lang/rust/issues/49804
"Stabilize
extended_varargs_abi_support
" rust#116161Link: https://github.com/rust-lang/rust/pull/116161
"Stabilize associated type position impl Trait (ATPIT)" rust#120700
Link: https://github.com/rust-lang/rust/pull/120700
"debuginfo: Stabilize
-Z debug-macros
,-Z collapse-macro-debuginfo
and#[collapse_debuginfo]
" rust#120845Link: https://github.com/rust-lang/rust/pull/120845
"False positives for the new
non_local_definitions
lint" rust#121746Link: https://github.com/rust-lang/rust/issues/121746
"Elaborate on the invariants for references-to-slices" rust#121965
Link: https://github.com/rust-lang/rust/pull/121965
"
#![crate_name = EXPR]
semantically allowsEXPR
to be a macro call but otherwise mostly ignores it" rust#122001Link: https://github.com/rust-lang/rust/issues/122001
"Proposal: Remove
i128
/u128
from theimproper_ctypes
lint" lang-team#255Link: https://github.com/rust-lang/lang-team/issues/255
"Decision on "must define before use" for opaque types" rust#117866
Link: https://github.com/rust-lang/rust/issues/117866
TC: The question is whether to adopt the following "must define before use" rule for opaque types:
This is a breaking change to RPIT. Here's an example of code that works today that would break under this rule:
This rule has relevance to the new trait solver.
TC: What do we think?
"TAIT decision on whether nested inner items may define" rust#117860
Link: https://github.com/rust-lang/rust/issues/117860
TC: The question is whether this should be true:
The context is that we allow this:
Should we accept spiritually-similar TAIT code unless and until we decide to go a different direction with the language?
"TAIT decision on "may define implies must define"" rust#117861
Link: https://github.com/rust-lang/rust/issues/117861
TC: The question is whether this should be true:
TC: This is important for the new trait solver.
TC: Here's one reason for that. The new trait solver treats strictly more code as being a defining use. It's also more willing to reveal the hidden type during inference if that hidden type is defined within the same body. This rule helps to avoid inference changes when moving from the old solver to the new solver. Adding this restriction makes TAIT roughly equivalent to RPIT with respect to these challenges.
TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque.)
"TAIT decision on "may not define may guide inference"" rust#117865
Link: https://github.com/rust-lang/rust/issues/117865
TC: The question is whether this should be true:
Here's the door that this would close:
TC: This is of importance to the new trait solver.
TC: Here's one reason for this. When we're type checking a body and we find an opaque type, we sometimes have to decide, should we infer this in such a way that this body would define the hidden type, or should we treat the type as opaque (other than auto trait leakage) and infer based on that? Depending on that, we can get different answers.
TC: If we did not let inference rely on this, then we would be closing the door on later allowing inference to rely on this without provoking changes in inference.
TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque. Answering this question in the affirmative would update one element of the #107645 FCP.)
Action item review
Pending lang team project proposals
None.
PRs on the lang-team repo
"Add soqb`s design doc to variadics notes" lang-team#236
Link: https://github.com/rust-lang/lang-team/pull/236
"Update auto traits design notes with recent discussion" lang-team#237
Link: https://github.com/rust-lang/lang-team/pull/237
RFCs waiting to be merged
"RFC: patchable-function-entry" rfcs#3543
Link: https://github.com/rust-lang/rfcs/pull/3543
S-waiting-on-team
"[ptr] Document maximum allocation size" rust#116675
Link: https://github.com/rust-lang/rust/pull/116675
"warn less about non-exhaustive in ffi" rust#116863
Link: https://github.com/rust-lang/rust/pull/116863
"offset: allow zero-byte offset on arbitrary pointers" rust#117329
Link: https://github.com/rust-lang/rust/pull/117329
"Add
wasm_c_abi
future-incompat
lint" rust#117918Link: https://github.com/rust-lang/rust/pull/117918
"Rename
AsyncIterator
back toStream
, introduce an AFIT-basedAsyncIterator
trait" rust#119550Link: https://github.com/rust-lang/rust/pull/119550
"privacy: Stabilize lint
unnameable_types
" rust#120144Link: https://github.com/rust-lang/rust/pull/120144
"Don't make statement nonterminals match pattern nonterminals" rust#120221
Link: https://github.com/rust-lang/rust/pull/120221
"debuginfo: Stabilize
-Z debug-macros
,-Z collapse-macro-debuginfo
and#[collapse_debuginfo]
" rust#120845Link: https://github.com/rust-lang/rust/pull/120845
"restrict promotion of
const fn
calls" rust#121557Link: https://github.com/rust-lang/rust/pull/121557
"Allow
#[deny]
inside#[forbid]
as a no-op with a warning" rust#121560Link: https://github.com/rust-lang/rust/pull/121560
"Split refining_impl_trait lint into _reachable, _internal variants" rust#121720
Link: https://github.com/rust-lang/rust/pull/121720
Proposed FCPs
Check your boxes!
"RFC: inherent trait implementation" rfcs#2375
Link: https://github.com/rust-lang/rfcs/pull/2375
"unsafe attributes" rfcs#3325
Link: https://github.com/rust-lang/rfcs/pull/3325
"MaybeDangling" rfcs#3336
Link: https://github.com/rust-lang/rfcs/pull/3336
"Add text for the CFG OS Version RFC" rfcs#3379
Link: https://github.com/rust-lang/rfcs/pull/3379
"RFC: Syntax for embedding cargo-script manifests" rfcs#3503
Link: https://github.com/rust-lang/rfcs/pull/3503
"Reserve
gen
keyword in 2024 edition forIterator
generators " rfcs#3513Link: https://github.com/rust-lang/rfcs/pull/3513
"add float semantics RFC" rfcs#3514
Link: https://github.com/rust-lang/rfcs/pull/3514
"RFC: New range types for Edition 2024" rfcs#3550
Link: https://github.com/rust-lang/rfcs/pull/3550
"Tracking issue for function attribute
#[coverage]
" rust#84605Link: https://github.com/rust-lang/rust/issues/84605
"Stabilise inline_const" rust#104087
Link: https://github.com/rust-lang/rust/pull/104087
"Implement
PartialOrd
andOrd
forDiscriminant
" rust#106418Link: https://github.com/rust-lang/rust/pull/106418
"Stabilize
anonymous_lifetime_in_impl_trait
" rust#107378Link: https://github.com/rust-lang/rust/pull/107378
"Report monomorphization time errors in dead code, too" rust#112879
Link: https://github.com/rust-lang/rust/pull/112879
"[ptr] Document maximum allocation size" rust#116675
Link: https://github.com/rust-lang/rust/pull/116675
"Stabilize Wasm target features that are in phase 4 and 5" rust#117457
Link: https://github.com/rust-lang/rust/pull/117457
"Stabilize Wasm relaxed SIMD" rust#117468
Link: https://github.com/rust-lang/rust/pull/117468
"Add
REDUNDANT_LIFETIMES
lint to detect lifetimes which are semantically redundant" rust#118391Link: https://github.com/rust-lang/rust/pull/118391
"privacy: Stabilize lint
unnameable_types
" rust#120144Link: https://github.com/rust-lang/rust/pull/120144
"Stabilize associated type position impl Trait (ATPIT)" rust#120700
Link: https://github.com/rust-lang/rust/pull/120700
"Allow
#[deny]
inside#[forbid]
as a no-op with a warning" rust#121560Link: https://github.com/rust-lang/rust/pull/121560
"regression: let-else syntax restriction (right curly brace not allowed)" rust#121608
Link: https://github.com/rust-lang/rust/issues/121608
Active FCPs
"Tracking issue for Allow a re-export for
main
(RFC 1260)" rust#28937Link: https://github.com/rust-lang/rust/issues/28937
"
c_unwind
full stabilization request: change inextern "C"
behavior" rust#115285Link: https://github.com/rust-lang/rust/issues/115285
"Prevent opaque types being instantiated twice with different regions within the same function" rust#116935
Link: https://github.com/rust-lang/rust/pull/116935
"Add
wasm_c_abi
future-incompat
lint" rust#117918Link: https://github.com/rust-lang/rust/pull/117918
"Consider linting against 00B7 aka interpunct aka middle dot" rust#120797
Link: https://github.com/rust-lang/rust/issues/120797
"debuginfo: Stabilize
-Z debug-macros
,-Z collapse-macro-debuginfo
and#[collapse_debuginfo]
" rust#120845Link: https://github.com/rust-lang/rust/pull/120845
"Split refining_impl_trait lint into _reachable, _internal variants" rust#121720
Link: https://github.com/rust-lang/rust/pull/121720
"Stabilize associated type bounds (RFC 2289)" rust#122055
Link: https://github.com/rust-lang/rust/pull/122055
P-critical issues
None.