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.
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: This RFC is now in FCP.
Tracking issue for promoting
!
to a type (RFC 1216) #35121Link: https://github.com/rust-lang/rust/issues/35121
TC: We discussed this in the design meeting on 2024-03-13. We then agreed to meet with Waffle on Tuesday to follow up. We stood him up though.
TC: Separately, though, Waffle and I have been discussing some steps in the path forward. He's making it possible to test the effect of various options discussed in the playground, e.g.:
TC: He's also working to do crater runs for some of these options. These steps seem likely to be useful input to the follow on discussions that we'll have.
Nominated RFCs, PRs, and issues (meeting 1)
"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: This issue also relates to the subject of the 2024-03-06 RfL meeting on
KernelArc
:https://hackmd.io/OCz8EfzrRXeogXEDcOrL2w
TC: The feeling in that meeting was that the
newtype
approach would probably work forRfL
along with thederive(SmartPointer)
approach that CE had proposed.TC: I'm writing up a document to bring together the situation and the various views. So I may reach out to you to set up a call to be sure your views and concerns are faithfully represented.
"Tracking issue: deref patterns" rust#87121
Link: https://github.com/rust-lang/rust/issues/87121
TC: Nadri has restarted work on deref patterns. We have a project repo for this:
https://github.com/rust-lang/project-deref-patterns
And we have an issue for the initiative / project group:
https://github.com/rust-lang/lang-team/issues/88
Apparently cramertj was the liaison for this. Nadri is looking for a new liaison.
TC: I've been working with Nadri on various things recently, so I'd be happy to take this (with the T-lang-op hat on) if this would be useful.
tmandry: Be good if you'd take this on.
pnkfelix: +1.
CE: We first want to get this all working.
Consensus: TC will take this one.
"Add
REDUNDANT_LIFETIMES
lint to detect lifetimes which are semantically redundant" rust#118391Link: https://github.com/rust-lang/rust/pull/118391
TC: We discussed this on 2023-12-13 and made a request for the lint to be broken into separate lints for unnecessary and unused lifetimes.
TC: This was done, and in the 2023-12-20 meeting, we discussed and the feeling was that we should do this, resulting in a proposal for FCP merge.
TC: We've been holding people out on this pending one last checkbox, so lcnr has renominated this for us.
pnkfelix: I've checked off.
Consensus: Now in FCP.
"Stop skewing inference in ?'s desugaring" rust#122412
Link: https://github.com/rust-lang/rust/pull/122412
TC: Waffle nominates this breaking change for us:
This prevents
!
from thereturn
from skewing inference:TC: This seems a clear case of testing our RFC 1122 rules of whether we can in fact make certain changes to inference behavior.
TC: What do we think?
scottmcm: Maybe rather than changing the desugaring is an indication that we should just go ahead and change
return
to do this.scottmcm: It'd make me happy if we could do something more general so as to keep the desugaring of
?
.tmandry: I agree with scottmcm's inclinations. It'd be unfortunate to have to special-case
?
in this way. So makingreturn
evaluate to an unbound type variable makes sense to me.pnkfelix: Could we go ahead with the
?
change anyway rather than blocking on the hypothetical?tmandry: I'm probably worried that we end up having to live with this special case forever.
TC: Part of the context here is that this is the smallest possible breaking change that moves us toward what we probably want to do to enable the never type.
tmandry: Part of me wants to kick this to the types team, but maybe they'd have the same answer.
scottmcm: This is a very subtle breaking change. I don't disagree that we could do this.
pnkfelix: It's odd to hesitate on changing this but support changing
return
generally.scottmcm: This seems to raise the same questions for me as the larger changes, e.g. with respect to subtle breakage. This feels a bit like a hack. If we already have a project looking at changing how
!
works, maybe we should do the larger change.tmandry: If this is an incremental change as part of that larger project, then this makes sense to me.
TC: That is the idea.
scottmcm: Maybe I can leave a comment asking about changing the behavior of
return
generally.pnkfelix: Based on https://github.com/rust-lang/rust/issues/51125, I am under the impression that changing
?
is meant to address known footguns with unsafe code.pnkfelix: I feel like we're in the state we're in because of earlier decisions. So I'm skeptical that blocking makes sense here.
Consensus: Let's wait for the crater run and ask Waffle about the possible change to
return
, and when we reapproach this, we'll pull in those examples that pnkfelix linked.tmandry: I definitely want to encourage this work. I want the never type to happen.
scottmcm: +1.
"recursively evaluate the constants in everything that is 'mentioned'" rust#122568
Link: https://github.com/rust-lang/rust/pull/122568
TC: We had an in-progress proposed FCP on this issue, which is a blocker to inline
const
:"Report monomorphization time errors in dead code, too" - #112879
https://github.com/rust-lang/rust/pull/112879
This proposed FCP had 4 boxes checked, but it never actually completed due to a concern we filed over a regression in incremental build times.
RalfJ analyzed that regression, so we now understand the cause of it:
https://github.com/rust-lang/rust/pull/112879#issuecomment-1987198783
This resulted in the present PR that solves the issue blocking inline
const
with a much more modest (and expected) performance regression.TC: Since the only thing that stopped the #112879 FCP is a concern over performance, and this solves it, do we want to treat the question in #112879 as having been decided, or do we want to start a new FCP on this PR?
TC: We could also decide that this question was fully decided by RFC 3477:
https://rust-lang.github.io/rfcs/3477-cargo-check-lang-policy.html
tmandry: As I recall, the reason we had the FCP was due to the perf regression. What's the case here?
TC: It's on the order of magnitude of 3% worst case, but there are improvements also.
scottmcm: And there are no wall time check regressions.
https://perf.rust-lang.org/compare.html?start=1eb882ef6d8630109c7b7ea5dcc5ef1c504bb976&end=02d1d38e5c2ce4f8986df3c3be1eea8e29d6199d&stat=wall-time&nonRelevant=true
scottmcm: Concretely, I'd say we're fine with this going in without FCP, then we start FCP to stabilize inline const.
tmandry: +1 on that.
scottmcm: We actually already have an in-progress FCP on that.
Consensus: We're OK with this one going in without FCP on the basis of the RFC.
scottmcm: inline_const pFCP: https://github.com/rust-lang/rust/pull/104087
"Const-eval errors in dead functions are optimization-dependent" rust#107503
Link: https://github.com/rust-lang/rust/issues/107503
TC: We've been treating optimization-dependent errors as a blocker for inline
const
. We had thought the last of these was addressed by:https://github.com/rust-lang/rust/pull/122568
TC: However, it's recently been observed that the cross-crate inlining heuristic also exhibits optimization-dependent behavior:
https://github.com/rust-lang/rust/issues/107503#issuecomment-2008088416
(There is further analysis that follows that comment that is worth reading.)
TC: Do we have thoughts on what next step to take on this?
tmandry: This seems like a bug.
Ben Kimock: Yes.
tmandry: I propose consensus that we fix this bug.
Ben Kimock: Items that have the inline attribute are lazily monomorphized. So if they're never used, they're never included.
Ben Kimock: There's a lot of entanglement in the compiler with these different layers. It's exciting that RalfJ has stepped up to start untangling this.
scottmcm: Certainly anything that's about optimized MIR is a place where I get concerned.
Ben Kimock: What RalfJ is proposing is separating those things.
TC: Do we want to proceed on stabilizing inline const and fix this in parallel or block inline const on this?
tmandry: It does seem like the other things we said we wanted to fix.
scottmcm: This was the original concern we filed in 2023:
https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210
Do we feel those have been sufficiently addressed?
scottmcm: Personally, I feel if we get the fix for the first problem, I'd be happy to move forward on inline const at least.
tmandry: My sense is that this is optimization-dependent.
scottmcm: Right, there's a heuristic for whether things get marked inline.
tmandry: That definely concerns me. It seems to fall under the category of things we should definitely fix. But I'm hearing some hesistance for blocking this from moving forward.
scottmcm: At least for me, there's an arguable distinction here. Since it's dead code, that maybe seems less bad. What we cared about was when you had a const that you really were using.
tmandry: Right, the main concern with optimization-dependent errors was that code that compiled one day would stop compiling on another day. Other than directly due to fixing this bug, that wouldn't be the case here.
tmandry: So this seems like a bad bug, but maybe this doesn't need to be a blocker to inline const.
Consensus: This seems like a bug that we should fix without FCP.
Proposed consensus for wider discussion with more attendance: As soon as Ralf's change is merged in, we're OK with moving forward with inline const.
(The first meeting ended here.)
Nominated RFCs, PRs, and issues (meeting 2)
"Tracking issue for RFC 2102, "Unnamed fields of struct and union type"" rust#49804
Link: https://github.com/rust-lang/rust/issues/49804
TC: fmease nominates this for us:
TC: That comment from RalfJ is:
TC: What do we think?
CE: I'm not a fan of the implementation. I don't think the RFC thought this through. I'd be happy if we were to start from scratch here.
fmease: This could have an ecosystem impact. That's part of what RalfJ's concern probably was.
Nadri: This is an older RFC. We need to recheck whether a language feature of this complexity is still worth it for perhaps a small use case.
CE/fmease: +1.
scottmcm: I like the point about the derive macros. If everyone who uses this complains to their upstreams, then it's hard for me to see that it's worth it.
tmandry: There seem to be two alternatives on the table here. One is generating named types. And the other is using anonymous types in the type.
Nadri: My understanding is that anonymous types don't even solve the problem here. They're not required or useful.
CE: Do we want to de-RFC this?
tmandry: I hesistate as we probably want more context here.
CE: I feel like this is floating without anyone pushing this forward. It's just kind of hanging out there.
scottmcm: I like the idea tmandry raised of using rfcbot as a feedback mechanism here. I'd be happy to see a de-RFC here, e.g. from the compiler people.
Nadri: There seem to be a lot of language problems here. It'd be good to have a design meeting about the problem that we're trying to solve here.
Nadri: it would make sense for the lang team to say "we're interested in solving this problem, but this proposed solution may not make sense in today's rust; let's reevaluate"
RalfJ: It seems worth asking what the current thinking is. It's probably not worth doing this just because C does it.
RalfJ: The libc people are now asking for it, so a case could be made. But it should be made based on Rust today.
tmandry: Looking at the RFC, there are aspects of this that I would like to exist in some form.
fmease: Where should the burden of proof fall here?
tmandry: It would be helpful if someone could summarize the arguments against. Maybe we could use the rfcbot poll feature.
RalfJ: There's a connection with C++ inheritance here.
Oli: People are trying to add that also.
CE: I'll try to summarize the concerns here.
Consensus: We have concerns about this. CE will write those out, then we could kick off an rfcbot poll. We'd like to know more about the motivation for this in terms of current Rust. Perhaps this would be good for a design meeting.
"regression: encountered mutable pointer in final value when "outer scope" rule applies in const/static with interior mutability" 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: There is some additional background on promotion and the related problems here:
https://github.com/rust-lang/rfcs/blob/master/text/3027-infallible-promotion.md
RalfJ: We evaluate the constant then put it into the global store. We have to decide what the mutability should be. When it's a constant, not a static, we'd like these all to be completely immutable. We hope to stabilize
const_mut_ref
soon. We want to ensure these can't make their way into constants.RalfJ: Everything about this worked great in crater except for one regression.
RalfJ: There's a mismatch between how various parts of the compiler look at this.
tmandry: I'm trying to get a sense of the cost of doing value-based reasoning in both cases. Could we have different rules for
const
?RalfJ: It doesn't work because we do promotion everywhere.
tmandry: And the reason that opsem doesn't want value-based reasoning is that it would make it more difficult to do runtime reasoning like miri does?
RalfJ: There are several reasons. It's bad if we have to only sometimes do value-based reasoning. We should do it everywhere or nowhere. Secondly, we like separating the permissions on the pointer from permissions on the value.
RalfJ: The problem is that even breaking these six crates only solves the less annoying part of the issue. The real problem is the promotion.
Oli: Could we just remove promotion in general over an edition and require people to use inline const? We can in fact run borrow checking twice; we did this for NLL. And the lint we emit would not have to be perfect. Most of the errors here would be quite obvious.
scottmcm: It'd be an interesting experiment. Maybe it's not no promotion at all, but maybe we cut it back to e.g. primitive types.
Oli: We could break promotion over an edition to be entirely type-based reasoning.
RalfJ: There's still the question of what to do about this regression.
TC: We already backported a fix here to turn this into a future-incompat.
tmandry: I'd propose we go with that for an edition or two.
RalfJ: The challenge is that I don't want to stabilize
const_mut_ref
until we do something better here.Oli: We could turn it into a hard error as soon as there's a mutable reference in the constant.
tmandry: I'm also OK with the mut reference hack if that would be temporary.
scottmcm: It would be nice if, on the basis of data, we could do the simpler thing.
RalfJ: It sounds like, in terms of next steps, we should do a crater run for converting to entirely type-based reasoning.
scottmcm: One thing that comes to mind is that if this is about the tail expression bit, there are people looking at that tail expression rule. Maybe it's worth feeding to them the fact that this is awkward. Maybe that could be fit into the other changes being proposed for Rust 2024.
RalfJ: I had thought about that briefly and I don't think that helps. This rule takes effect before we have type information.
TC: To summarize next steps:
RalfJ: The vibe here seems more in favor of breaking that crate than adding a special exception with value-based reasoning.
tmandry/scottmcm: +1.
RalfJ: I'm torn between having two ugly things that are consistent versus having two less ugly but inconsistent things.
(Post-meeting notes:)
Follow-on discussion of this is here:
https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Value-based.20interior.20mutability.20in.20promotion.20.2F.20tail.20expr
An older related issue:
"const checking: do not do value-based reasoning for interior mutability" - #121786
https://github.com/rust-lang/rust/pull/121786
An example of promotion introducing UB as discussed above:
https://github.com/rust-lang/unsafe-code-guidelines/issues/493
"restrict promotion of
const fn
calls" rust#121557Link: https://github.com/rust-lang/rust/pull/121557
TC: RalfJ nominates this for us:
TC: We discussed this without resolution in the meeting on 2024-03-13. We discussed how having inline
const
blocks could move us in a direction of solving these problems more generally.Those were blocked on incremental build-time regressions in:
https://github.com/rust-lang/rust/pull/112879
However, RalfJ has now analyzed this here:
https://github.com/rust-lang/rust/pull/112879#issuecomment-1987198783
…and has a superseding PR that solves the problem which a much more modest performance regression:
https://github.com/rust-lang/rust/pull/122568
scottmcm: If the hope here is to go to the simpler thing once we have inline_const, and thus this is sort of temporary (if perhaps not completely temporary because old editions), then I think I'm fine with it. I also don't love it, but if it's a good step, then great.
tmandry: +1.
tmandry: Question is whether Ralf still wants to go forward if inline consts look much closer to stabilizing now.. from the description it sounds like probably yes.
RalfJ: Yes, I'd still want to land this even with inline const.
tmandry: I'll go ahead and start the FCP here then.
(The second 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 about a path toward async drop and scoped tasks:
https://github.com/rust-lang/compiler-team/issues/727
TC: petrochenkov gives some background:
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 about a path toward async drop and scoped tasks:
https://github.com/rust-lang/compiler-team/issues/727
TC: petrochenkov gives some background:
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 about a path toward async drop and scoped tasks:
https://github.com/rust-lang/compiler-team/issues/727
TC: petrochenkov gives some background:
TC: The question here is whether we want to charter this as an experiment.
"privacy: Stabilize lint
unnameable_types
" rust#120144Link: https://github.com/rust-lang/rust/pull/120144
TC: petrochenkov implemented the last piece of RFC 2145 ("Type privacy and private-in-public lints"):
https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md
He's seeking to stabilize it. Here's what we're talking about:
TC: Back on 2024-02-14 we discussed this in a triage meeting and were feeling positive about it, resulting in an FCP merge. This has been waiting on one additional checkbox and petrochenkov has renominated this for us to see if we want to move forward.
TC: There's been some discussion on the name. I have to admit, my first reaction was, "this isn't what we mean by unnameable types in Rust". But then, after I worked through some examples (such as above) and thought about it, I realized that, yes, actually this is what we mean by unnameable types. In fact, the accepted RFC even specifically called these "Voldemort types":
https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md#lint-3-voldemort-types-its-reachable-but-i-cant-name-it
…and it suggested
unnameable_types
as the name for the lint.TC: Do we still want to move forward here?
"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?
"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?
"
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: In the 2024-02-21 meeting (with limited attendance), 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?
"Policy for lint expansions" rust#122759
Link: https://github.com/rust-lang/rust/issues/122759
TC: In the call on 2024-03-13, we discussed this issue raised by tmandry:
"Fallout from expansion of redundant import checking"
https://github.com/rust-lang/rust/issues/121708
During the call, the thoughts expressed included:
TC: tmandry volunteered to draft a policy proposal. He's now written up this proposal in this issue.
TC: What do we think?
"Raw Keywords" rfcs#3098
Link: https://github.com/rust-lang/rfcs/pull/3098
TC: We've at various times discussed that we had earlier decided that if we wanted to use a new keyword within an edition, we would write it as
k#keyword
, and for that reason, we prefer to not speculatively reserve keywords ahead of an edition (except, perhaps, when it's clear we plan to use it in the near future).TC: Somewhat amusingly, however, we never in fact accepted that RFC. Back in 2021, we accepted scottmcm's proposal to cancel:
Instead we accepted RFC 3101 that reserved
ident#foo
,ident"foo"
,ident'f'
, andident#123
starting in the 2023 edition.Reading through the history, here's what I see:
k#keyword
, but it's another to actually do it in the face of certain criticism about that being e.g. unergonomic. Would we follow through?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?
"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?
"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.
"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?"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?
"Stabilize
extended_varargs_abi_support
" rust#116161Link: https://github.com/rust-lang/rust/pull/116161
TC: This stabilization was nominated for us, with pnkfelix commenting:
TC: What do we think about 1) this stabilization, and 2) whether we want to own this?
"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."debuginfo: Stabilize
-Z debug-macros
,-Z collapse-macro-debuginfo
and#[collapse_debuginfo]
" rust#120845Link: https://github.com/rust-lang/rust/pull/120845
TC: This finished a T-compiler FCP, but ehuss nominates this for us on the grounds of policy:
TC: What do we think?
"False positives for the new
non_local_definitions
lint" rust#121746Link: https://github.com/rust-lang/rust/issues/121746
TC: There is discussion in the issue in which Urgau explains why this is not a false positive, but the reporter still thinks it's misleading, and Josh nominated this for us.
TC: What do we think?
"Elaborate on the invariants for references-to-slices" rust#121965
Link: https://github.com/rust-lang/rust/pull/121965
TC: scottmcm filed this issue and explains:
Then joboet nominated this for us with:
RalfJ thinks this should probably be a dual T-lang / T-opsem FCP.
TC: What do we think?
"
#![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
TC: fmease notes that:
TC: pnkfelix nominates this for us:
"Assert that the first
assert!
expression isbool
" rust#122661Link: https://github.com/rust-lang/rust/pull/122661
TC: estebank describes this issue for us:
TC: And pnkfelix nominates this for us:
"Emit a warning if a
match
is too complex" rust#122685Link: https://github.com/rust-lang/rust/pull/122685
TC: Nadri nominates this for us and describes the situation:
TC: What do we think?
"Proposal: Remove
i128
/u128
from theimproper_ctypes
lint" lang-team#255Link: https://github.com/rust-lang/lang-team/issues/255
TC: Trevor Gross describes the situation:
TC: Josh nominates this for our discussion. What do we think?
"Implement
PartialOrd
andOrd
forDiscriminant
" rust#106418Link: https://github.com/rust-lang/rust/pull/106418
TC: We discussed this last in the meeting on 2024-03-13. scottmcm has now raised on concern on the issue and is planning to make a counter-proposal:
https://github.com/rust-lang/rust/pull/106418#issuecomment-1994833151
"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?"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)]
."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
?!
,*
,&
)?"
.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?
"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?
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
"offset: allow zero-byte offset on arbitrary pointers" rust#117329
Link: https://github.com/rust-lang/rust/pull/117329
"Better errors with bad/missing identifiers in MBEs" rust#118939
Link: https://github.com/rust-lang/rust/pull/118939
"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
"[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
"Rename
AsyncIterator
back toStream
, introduce an AFIT-basedAsyncIterator
trait" rust#119550Link: https://github.com/rust-lang/rust/pull/119550
"Allow
#[deny]
inside#[forbid]
as a no-op with a warning" rust#121560Link: https://github.com/rust-lang/rust/pull/121560
"Experimental feature postfix match" rust#121619
Link: https://github.com/rust-lang/rust/pull/121619
Proposed FCPs
Check your boxes!
"unsafe attributes" rfcs#3325
Link: https://github.com/rust-lang/rfcs/pull/3325
"RFC: Syntax for embedding cargo-script manifests" rfcs#3503
Link: https://github.com/rust-lang/rfcs/pull/3503
"add float semantics RFC" rfcs#3514
Link: https://github.com/rust-lang/rfcs/pull/3514
"Tracking issue for function attribute
#[coverage]
" rust#84605Link: https://github.com/rust-lang/rust/issues/84605
"Implement
PartialOrd
andOrd
forDiscriminant
" rust#106418Link: https://github.com/rust-lang/rust/pull/106418
"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
"Let's
#[expect]
some lints: Stabilizelint_reasons
(RFC 2383) " rust#120924Link: https://github.com/rust-lang/rust/pull/120924
"RFC: inherent trait implementation" rfcs#2375
Link: https://github.com/rust-lang/rfcs/pull/2375
"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: New range types for Edition 2024" rfcs#3550
Link: https://github.com/rust-lang/rfcs/pull/3550
"Stabilise inline_const" rust#104087
Link: https://github.com/rust-lang/rust/pull/104087
"Stabilize
anonymous_lifetime_in_impl_trait
" rust#107378Link: https://github.com/rust-lang/rust/pull/107378
"[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
"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
"Reserve
gen
keyword in 2024 edition forIterator
generators " rfcs#3513Link: https://github.com/rust-lang/rfcs/pull/3513
P-critical issues
None.