or
or
By clicking below, you agree to our terms of service.
Sign in with Wallet
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.
Syncing
xxxxxxxxxx-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
SubscribeT-lang meeting agenda
Attendance
Meeting roles
Scheduled meetings
impl Trait" #215Edit 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!)
Action item review
Pending lang team project proposals
None.
PRs on the lang-team repo
"Frequently requested changes:
return expr if condition" lang-team#213Link: https://github.com/rust-lang/lang-team/pull/213
TC: The FCP merge is complete. It seems this can be merged.
RFCs waiting to be merged
None.
S-waiting-on-team"Tracking issue for dyn upcasting coercion" rust#65991
Link: https://github.com/rust-lang/rust/issues/65991
TC: Two weeks ago we agreed to proceed to an FCP if no data had been provided. We made a public request for data to this effect.
TC: Last week, we reviewed the data provided. It was mostly not surprising, but it led to discussion. We seemed open to an opt-out at the trait level and/or LTO or other compile-time options to control this.
TC: We discussed whether we should block on these options. It's technically an API breaking change for a crate to later opt-out a trait. But does it matter? We're already paying for this size increase in practice; the question here is whether to commit to it.
TC: One option discussed was to create an experiment for disabling this at the trait level. Then, if there proved demand for it, we could RFC and stabilize the experiment. @nikomatsakis was going to reach out to charleslf about this.
TC: Whether to continue moving forward without that option available seemed to be an open question.
TC: In the last week, @WaffleWapkin has posted an interesting issue that reports that VTables include certain uncallable methods: "This is especially sub-optimal in the presence of trait upcasting, since this makes otherwise empty (wrt to trait objects) traits non-empty, adding need for more vptrs."
TC: Seems to be waiting on @nikomatsakis; no new action this meeting.
"Create
unnecessary_send_constraintlint for&(dyn ... + Send)" rust#110961Link: https://github.com/rust-lang/rust/pull/110961
TC: The FCP merge is complete, but we're waiting on the author to make some final updates. We removed the nomination, but not the
S-waiting-on-team."Replace old private-in-public diagnostic with type privacy lints" rust#113126
Link: https://github.com/rust-lang/rust/pull/113126
TC: Last week we decided to move forward with this and started an FCP merge. It has three boxes checked.
TC: @nikomatsakis saw that the author had started a crater run. @nikomatsakis filed a concern based on this to check with the author that no backward-incompatible behavior was expected. The author has since responded to confirm that indeed no backward incompatible behavior is expected. In terms of why crater was used, the author responded that, "I wanted to check that all the effective visibility tables are filled correctly and nothing unexpected happens, since crater runs are pretty cheap now." Based on this, the concern should probably be removed.
TC: This meeting: we're waiting on @nikomatsakis to remove his concern.
Proposed FCPs
Check your boxes!
"unsafe attributes" rfcs#3325
TC: This seems to be blocked on a concern about the syntax, but we've also discussed lingering questions about the degree to which this is a good idea at all. The basic concerns can be summarized as:
unsafeprovides both a way to create an obligation (unsafe fn) and a way to discharge an obligation (unsafe { .. }).unsafe { .. }but cannot fully discharge the obligation within that function, you make it anunsafe fnto propagate the obligation upward.unsafe(..)in unsafe attributes seemingly does both. It can be read as, on the one hand, discharging the obligation created by, e.g.no_mangle, but on the other, it can't actually discharge that obligation without creating a new upward obligation.unsafe, is this really what we want to be encouraging about howunsafeis handled and how its obligations should be discharged?unsafe fn, documenting the invariants that must be upheld is what is needed so that the caller can appropriately discharge the obligation, but documenting it does not in and of itself discharge any obligations.)Josh: Seems we may be blocked on figuring out the syntax. Maybe we should review the options here in a consolidated way.
Josh: We may want to move forward with this give the 2024 edition, as we could then require this.
"RFC: UTF-8 characters and escape codes in (byte) string literals" rfcs#3349
TC: This is waiting on the author.
"Allow cfg-attributes in where clauses" rfcs#3399
TC: We decided this two weeks ago and decided it was a good idea. It's waiting on boxes to be checked.
"Tracking issue for the
thiscallcalling convention" rust#42202TC: T-lang has done what it needed to do here.
"Stabilise inline_const" rust#104087
Looks like our comments on https://github.com/rust-lang/rust/pull/112879#issuecomment-1641214618 are still relevant, nothing new.
scottmcm: We may be OK to move forward here; we discussed that we wanted this. Maybe we just need to resolve our concerns.
Lokathor: Dylan-DPC marked it as blocked on https://github.com/rust-lang/rust/issues/86730
(discussion about what we're actually blocked on, and that there may be unrelated things at play…)
Josh: Maybe write a comment to ask whether this should really be blocked on those other issues?
scottmcm: My guess: This would stabilize a new thing in expression starts.
scottmcm: This applies to
asyncblocks as well?scottmcm: Is this an existing problem that is true of other expression constructs?
David: It does not apply to
async.Lokathor: Should this go on the list of things to handle in 2024, give the divergence in the macro matcher? There's been a bullet point suggestion to fix this in 2024.
Josh: That seems appropriate to dig into. Is that currently present in our document of things to look into for 2024?
pnkfelix: It has the right label on it.
"Stabilize
anonymous_lifetime_in_impl_trait" rust#107378"TAIT defining scope options" rust#107645
"Lower
Orpattern without allocating place" rust#111752"Replace old private-in-public diagnostic with type privacy lints" rust#113126
Active FCPs
"add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053
Link: https://github.com/rust-lang/rust/pull/113053
"Mention style for new syntax in tracking issue template" rust#113586
Link: https://github.com/rust-lang/rust/pull/113586
"Make
unconditional_recursionwarning detect recursive drops" rust#113902Link: https://github.com/rust-lang/rust/pull/113902
P-critical issues
None.
Nominated RFCs, PRs and issues discussed this meeting
"Allow explicit
#[repr(Rust)]" rust#114201Link: https://github.com/rust-lang/rust/pull/114201
TC: The proposed change here would be insta-stable. @WaffleLapkin wants to know whether T-lang is OK with this.
Josh: Started FCP.
Josh: This seemed like an easy one to do.
scottmcm: I like this being something that you can literally say – see https://rust-lang.zulipchat.com/#narrow/search/.22repr.28rust.29.22 for lots for examples of different people already saying this on Zulip.
Josh: I can imagine that in a project where most things are
#[repr(C)]that you'd want to make the exceptions very clear.Lokathor: Should we discuss the insta-stable bit?
scottmcm: The proposed FCP includes whether it should be insta-stable.
"add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053
Link: https://github.com/rust-lang/rust/pull/113053
TC: This is entering FCP.
Josh: We started an FCP based on the nomination. We should probably unnominate this.
All: agreed.
"Lower
Orpattern without allocating place" rust#111752Link: https://github.com/rust-lang/rust/pull/111752
Un-nominating since it's going through an FCP.
"Tracking issue for
#![register_tool]" rust#66079Link: https://github.com/rust-lang/rust/issues/66079
TC: @xFrednet has summarized what may be blocking this issue:
Josh: The blocker has always been when and how you register a tool. Stabilizing this doesn't seem like a problem. But we should probably do this in some principled way rather than switching to a lint.
scottmcm: I'm wondering if there's any other pattern here that would be close. People had done work to list out the CFGs. For lints you want a nice way to suppress it. But for a lint rather than an error, I don't know. Maybe there's something there that's not completely horrible. No specific proposal though.
Josh: We had concerns the last time we looked at it. But most of those concerns were, is this the right answer? But it seems we're not seeing anything wildly better.
scottmcm: Putting it in the code seems better than passing it in a build script or as a command-line argument.
Josh: Maybe the requests we made previously for documentation still apply?
pnkfelix/Josh/scottmcm: An RFC is probably appropriate.
pnkfelix: If the proposal is about experimentation, then yes, it's going to need an RFC.
Lokathor: Does it need an RFC before or after reducing it to a lint trigger?
Josh: It would need consensus in some form to do that.
scottmcm: It would need an FCP since it's a one-way door.
Josh: If you want to do the downgrade thing, that needs an FCP.
pnkfelix: The chances of that going through might be stunted.
scottmcm: Downgrading it is also a stabilization. We'd like an RFC for what the stabilization plan should be.
pnkfelix: I'll make a comment to that effect.
"Explicit Tail Calls" rfcs#3407
Link: https://github.com/rust-lang/rfcs/pull/3407
TC: @WaffleLapkin has been working on an implementation.
Josh: I'm pulling this up for discussion. This seems to be pushing hard for an implementation. But it seems to be sidestepping the issue of "don't make the demo look done" with respect to choosing the syntax.
Josh: The premise is that you can go forward with a second and no objections. But I have objections.
Josh: I can't tell whether scottmcm's suggestion was an augmented or different approach.
scottmcm: Yes, it's a reasonable experiment to do on its own. I'm uncertain about the extent of oversight that lang should have on a compiler experiment. Not sure whether we should block experiments on syntax.
Josh: When we talked about the experiment process, we talked about second and no objections. People ask before doing an experiment to get a preview of what the answer would be. I'm suggesting here that the answer will be "no".
TC: Are you saying you would veto this syntax? In the ticket, it seemed like you wanted further discussion.
Josh: No, I just don't want to contaminate the experiment. So I'm objecting to the syntax for that experiment.
tmandry: Are you advocating an explicit syntax in its place?
Josh: I want something that's an obvious placeholder.
Lokathor: So a macro maybe?
Josh: Yes, some kind of placeholder.
scottmcm: I feel like a macro is not in and of itself enough.
tmandry: The
becomekeyword was reserved for this use-case.tmandry: That makes it seem like a fairly natural choice.
Josh: We now have a mechanism for picking arbitrary keywords and introducing it over an edition.
scottmcm: I'd like to let it land with
becomeand then change it to a placeholder or other possibilities if needed. Do we want them to implement all of them and let people try them all?Josh: I'd like people to try the feature and to ask them what they think it should be called.
tmandry: How is this currently blocked?
Josh: It's blocked because I'm telling them no unless they change something.
scottmcm: We should unnominate the RFC maybe since we're waiting on the experiment.
pnkfelix: Here is the PR.
Josh: A tracking issue has been opened. Some issues have been merged.
tmandry: Like scottmcm, I'm fine with
becomefor the placeholder, but Josh, if you have concerns, it seems you should state those clearly to halt the work."Document soundness of Integer -> Pointer -> Integer conversions in
constcontexts." rust#113510Link: https://github.com/rust-lang/rust/pull/113510
(Discussion about what's always been true and what may need to be documented…)
Josh: Concrete proposal for a next step. Anyone think this doesn't need an FCP?.. Hearing none.
Josh: I'll start an FCP to merge. We may want some changes. Maybe @scottmcm, you could immediately file a concern.
pnkfelix: We could land this hypothetically; it's just a step forward; we could later do what scottmcm is discussing.
scottmcm: I'll add comments to the effect of what we'e discussed. I'm also in favor of starting an FCP.
Nominated RFCs, PRs and issues NOT discussed this meeting
"MaybeDangling" rfcs#3336
Link: https://github.com/rust-lang/rfcs/pull/3336
TC: There's been considerable recent discussion of this over on Zulip.
"Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503
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.
"dyn Trait comparison should not include the vtable pointer" rust#106447
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.
"Make pointer_structural_match normal and warn" rust#110166
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.
"let-else does not support
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.
"RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods" rust#112194
Link: https://github.com/rust-lang/rust/issues/112194
TC: We handled this in the design meeting last week.
"Report monomorphization time errors in dead code, too" rust#112879
Link: https://github.com/rust-lang/rust/pull/112879
TC: This is a blocker for the stabilization of
inline_const. We discussed recently and decided we were OK with it. @tmandry posted a comment asking about a possible crater run. Nothing has moved here since."Replace old private-in-public diagnostic with type privacy lints" rust#113126
Link: https://github.com/rust-lang/rust/pull/113126
"Support overriding
warningslevel for a specific lint via command line" rust#113307Link: https://github.com/rust-lang/rust/pull/113307
"Tracking Issue for the Rust specification" rust#113527
Link: https://github.com/rust-lang/rust/issues/113527
"Mention style for new syntax in tracking issue template" rust#113586
Link: https://github.com/rust-lang/rust/pull/113586