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
Announcements or custom items
Niko: question for Felix
Any updates on compiler team horoscope relevant to this meeting? :)
Niko: traits/chalk oh my
Josh: Goal of having a team-full of people in that category of "sounds like a niko problem" would help.
Niko: impl trait refactor landed
Action item review
Pending lang team project proposals
"Deprecate target_vendor " lang-team#102
Link: https://github.com/rust-lang/lang-team/issues/102
"Async fundamentals initiative" lang-team#116
Link: https://github.com/rust-lang/lang-team/issues/116
"Attribute for trusted external static declarations" lang-team#118
Link: https://github.com/rust-lang/lang-team/issues/118
"Support platforms with size_t != uintptr_t" lang-team#125
Link: https://github.com/rust-lang/lang-team/issues/125
"Positional Associated Types" lang-team#126
Link: https://github.com/rust-lang/lang-team/issues/126
"Heap allocations in constants" lang-team#129
Link: https://github.com/rust-lang/lang-team/issues/129
"Interoperability With C++ Destruction Order" lang-team#135
Link: https://github.com/rust-lang/lang-team/issues/135
"inner crates, aka multiple crates per file" lang-team#139
Link: https://github.com/rust-lang/lang-team/issues/139
"allow construction of non-exhaustive structs when using functional update syntax" lang-team#143
Link: https://github.com/rust-lang/lang-team/issues/143
PRs on the lang-team repo
None.
RFCs waiting to be merged
None.
Proposed FCPs
Check your boxes!
"Tracking Issue for RFC #2972: Constrained Naked Functions " rust#90957
Link: https://github.com/rust-lang/rust/issues/90957
"Make
unused_lifetimeslint warn-by-default" rust#92386Link: https://github.com/rust-lang/rust/pull/92386
Note: oh, it's tagged as waiting-on-author, but that doesn't cause it to be omitted from this list
simulacrum: it may be worth cancelling this FCP, it seems clear that the changes aren't going to happen in this PR, and re-evaluating in 3 or 4 weeks time whether the concerns have been addressed, some part of me feels we should cancel the FCP when it's ready to try again.
josh: you're proposed we close the PR and ask for a new one to be opened once the concerns are addressed?
simulacrum: yes. Essentially "no, this is not ready yet"
josh: seems reasonable, change will not be in this PR, while we can leave it open while other PRs get merged, we might also just want to pause it.
nikomatsakis: I'm in favor, but let's document the concerns in the tracking issue.
josh: worth documenting that we had enough checkboxes to get consensus, so folks can assume that if we do those named items, reasonable to expect that the next FCP will succeed.
simulacrum: I'll take an action item to type a comment, close the PR, and either filing or repurosing a tracking issue.
josh: my point is, sometimes people don't write out all their concerns so long as there is one, if folks have other objections beyond those currently registered, please do explicit list them so people know what to work on. Want to avoid whack-a-mole.
nikomatsakis: makes sense.
simulacrum: yes, though I don't think we can promise no future concerns will be raised.
josh: :thumbs-up:
"Check if enum from foreign crate has any non exhaustive variants when attempting a cast" rust#92744
Link: https://github.com/rust-lang/rust/pull/92744
joshtriplett: awaiting a few check boxes
pnkfelix: this is waiting on a revised design, right? Hooked into the stuff about enums and reprs?
joshtriplett: I think this is independent, part of a decision we already made in a previous round, specifically that we want to not allow you to do an
ascast on an enum from another crate, since that cast could stop working if you add variants or fields to the enum (as non-exhaustive is meant to permit).nikomatsakis: I feel like this is a no-brainer and everyone in this meeting should check their box or ANSWER TO ME ;)
scottmcm: in particular this is not related to the question of empty parens or braces or whatever, because non-exhaustive allows adding entire fields, which has never been allowed
nikomatsakis: or new variants!
scottmcm: this is specifically about non-exhaustive on the variant
nikomatsakis: we should check the variant case
pnkfelix: deja vu, didn't we talk about this last time??
/me nikomatsakis makes up dialog
"Stabilize
let else" rust#93628Link: https://github.com/rust-lang/rust/pull/93628
scottmcm: I put a concern on this about rustfmt. Seems like a good conversation to have. I think I will remove my concern about rustfmt.
joshtriplett: I think Niko's concern about needing a stabiliztion report is still blocking. That said, the other concern about rustfmt, there are narrow cases where we would potentially block on rustfmt, but I don't think this is currently one. calebcartwright said that while they don't change the syntax of rustfmt once it's established, they consider it acceptable to define the syntax once. I do think we should avoid the chicken-and-egg problem. Worth discussing.
scottmcm: I'm a little surprised by that position. Not sure what makes it easier to break everyone's CI by adding formatting the first time, as opposed to only later when they decide on the official one?
simulacrum: The main reason is that, the way rustfmt works, you have some users locally developing on nightly. This is usually fine. But with formatting, if your nightly compiler locally is using rustfmt, and it has introduced a chance, you save the file, it changes stuff, and when you submit it to CI, that expects a different kind of formatting, and now you have to change your toolchain locally to use this project – often a pain in the neck.
nikomatsakis: that makes sense, but how does that address the "no rule enforced" but then they added one?
simulacrum: when nothing is enforced, the stable CI will not complain, because it will be preserved.
joshtriplett: I see, I see. rustfmt will allow whatever you use, so it won't change your formatting, so CI won't see a diff and complain. At some point, we add something in rustfmt, and there's a one-time issue of matching that format.
to summarize:
In practice, many people pin to stable, so they do experience a problem, but that is also true for lints.
nikomatsakis: I think we should think about how to make upgrading less painful. I also think distinguishing "the language for this is stable, but it's not fully ready for use".
joshtriplett: I have some concerns, but yes
scottmcm: it seems hard to do for things that use CI
nikomatsakis: why? ok, let's talk later
joshtriplett: in practice anyway, there is a bit of a race between rustfmt and codebases actively adopting.
Active FCPs
"Tracking issue for naked fns (RFC #1201)" rust#32408
Link: https://github.com/rust-lang/rust/issues/32408
Reminder: this is associated with constrained naked functions above.
Has enough checkboxes to go forward. Reminder to raise concerns.
"Positional Associated Types" lang-team#126
Link: https://github.com/rust-lang/lang-team/issues/126
"Interoperability With C++ Destruction Order" lang-team#135
Link: https://github.com/rust-lang/lang-team/issues/135
P-critical issues
None.
Nominated RFCs, PRs and issues
24 minutes, 7 items, 3 minutes per item! No! More! Niko can't do math!
"Stabilize
#[cfg(panic = "...")]" rust#93658Link: https://github.com/rust-lang/rust/pull/93658
Allows you to use different code based on panic strategy (panic=unwind, panic=abort). Had this implementation in October 2 years ago. Available for a while, would be reasonable to stabilize.
simulacrum: Back when we first landed it, there were concerns about stability, likely misuse, might be use relinking those concerns and including them in a stabilization report as addressed.
joshtriplett: I can make a note that when this is discussed in the release notes we should remind people to avoid writing code that assumes there are only two panic strategies and that "not panic=unwind" means "panic=abort" and vice versa.
simulacrum: I think some of those concerns were about incompatibility.
nikomatsakis: I feel like that's already a thing…
simulacrum: not new concerns, portability lint, but they should be mentioned at the FCP start.
nikomatsakis: this also allows you to be more compatible, e.g. libtest relies on unwinding and conceivably you could use this flag to launch processes or be compatible in some other way.
joshtriplett: any final concerns before I start FCP?
nikomatsakis: DO IT
scottmcm: DO IT
"
no_mangle/usedstatic is only present in output when in reachable module" rust#47384Link: https://github.com/rust-lang/rust/issues/47384
nikomatsakis: what's the deal here
joshtriplett: Apparently this bug is a regression causing some issues in the ecosystem
mara: an old issue that changes over time and gets slightly worse. People use statics to get stuff to the linker and hope that it gets preserved. Sometimes entire objects are dropped if you don't use anything from a module, depending on how things are distributed, which changes between compiler versions, codegen-units, etc. There were two crates from david tolnay, linkme and xxx, that permit you to "gather up" things like the test framework does. Those crates kept being buggy because of this issue. Workaround was codegen-units=1 but dtolnay archived and deprecated those crates because of issues.
(scottmcm: aside, I want
distributed_slicein the language https://internals.rust-lang.org/t/from-life-before-main-to-common-life-in-main/16006/25?u=scottmcm)nikomatsakis: what's the lang team call here?
mara: whether it should guarantee?
joshtriplett: I think the question is:
#[used], that symbol will end up in the final binary? (And ditto#[no_mangle]?)If that's not the case, then
#[used]has remarkably little value. You might ask what use it has.mara: it suppresses some lints. Even if answer is no, people will ask for a new attribute.
simulacrum: there are apparently two different semantics. We guarantee it makes it to the linker or we guarantee linker will emit it in the final binary. Makes it to the linker is plausible, but making it through the linker is hard-to-impossible with current platforms, at least according to the thread.
joshtriplett: Original issue opened here involved a custom linker script. In the face of that, we can make no guarantees. If you don't have a custom linker script, or you're not doing anything weird, can we guarantee it all the way through the linker?
nikomatsakis: this is kind of outside my detailed knowledge area, I would like to have a good place to settle these sorts of linker and low-level questions.
joshtriplett: I think there's a decision we can make. Do we define that
#[used]carries something through to the final binary or do we decide that it doesn't (and people should add a new one)? Somebody commented a few days back saying that this is equivalent to what gcc's used does, and therefore they think rustc is behaving properly, and there's a separate attribute, called retain, that does what they want.simulacrum: this is the compiler/linker distinction I was getting at, fwiw. Some linkers apparently don't support retain.
joshtriplett: We could say that
#[used]does mean retain, and if people want the weaker thing, we could do that.Mara:
#[used]guarantees it gets into the object file, but it's not clear which one, and if it ends up in a file from which nothing is used, then it gets dropped. In gcc/clang it's much easier to tell which.ofile it will wind up in.Felix: We could solve the codegen-units interaction.
Mara: I think an important thing that's missing from that comment, Josh, is that Rust doesn't give you control.
Niko: This sounds like a bug to me, it sounds like we should guarantee that it gets you "up to the final linking step".
Lokathor: don't forget custom linker script.
Josh: See
pnkfelix: I agree, I just want to say that gcc/clang having 2 separate attributes to denote these slightly different things means we have to match their behavior. To me,
#[used]historically has meant "try your best to get it through the compiler/linker", and if people want the more precise controls,#[used]should mean "We do our damndest to get it through", modulo linker scripts and what not.joshtriplett: Agreed, making
#[used]do what most people want would be good, but this comment to points out that there is a use-case for#[used](in the gcc sense) and a concern that#[retain]is not supported by all toolchains, so it may not be viable to declare that "our used means retain all the way through linking".pnkfelix: is it ignored?
joshtriplett: in best case, worst case it creates a miscompilation, so it is not as simple as "let's do the thing people want", because that may not be supported.
mara: I feel like the
#[used]attribute is buggy in the case of multiple codegen-units, which can be fixed, and that adding something that is "used but not retain" is just a feature request.mara: It's a but unclear what "do our best to make it to the linker means", e.g., if you don't use a crate at all, that seems fine, people are not surprised. but the main problem is if you add it to a modulo, and the module ends up in a separate
.ofile, that might disappear, so making sure it ends up in the final binary, even though the entire crate is not used, is more theretainproblem and doesn't fall on the gcc used attribute either. Not even possible in some object formats and linkers.scottmcm: what I heard that I definitely agree with is that the pieceo of this that is specific to "codegen units" is "just a bug" and doesn't need lang team consideration, under the "multiple cgu should work" requirement, and that can be solved without more conversation.
mara: yeah I think if that gets solved the rest of the conversation gets a lot simpler.
nikomatsakis: what I don't know is whether, on some platforms, the bug that affects
#[used]also affects trying to merge together codegen units? I guess that's an impl problem that rustc would have to resolve.mara: you would probably have to put used things into one CGU.
joshtriplett: I think it's a useful clarification to say that "not getting as far as the linker" is a regression that should be fixed, and this can be fixed orthogonally from extending used.
mara: I think that's right.
joshtriplett: mara, are you up to write the above as a summary?
mara: I don't know much about CGUs, I just know setting it to 1 fixes things, felix, maybe you're the right person?
pnkfelix, softly and with apparent lack of eagerness: ok
joshtriplett: I'll do it!
"Tracking Issue for scoped threads" rust#93203
Link: https://github.com/rust-lang/rust/issues/93203
mara: I want this stabilized! This RFC has been around for ages! Super nice! Recent addition to the stdlib!
Open question about whether the interface could be nicer. Some open questions about whether it could be nicer to capture things by copy in some cases instead of "by reference", don't know the details, the situation is relatively complicated. Probably too much for this meeting. Would need someone with a lot of knowledge to take a good look to take a good look and tell us if this change is realistic or what. I'm afraid it will get stuck for the whole year.
nikomatsakis: I will read it and give thoughts. I think I know what's going on here.
nikomatsakis volunteers to read and respond
"[experiment] proc-macro: Stop wrapping
identmatchers into groups" rust#92472Link: https://github.com/rust-lang/rust/pull/92472
josh: we don't have time to go into detail, but people should look at this, we discussed in libs, I think it needs lang signoff, straightforward change that is reasonably explained in the thread.
Not discussed (yet?)
"Automatically implement AsRepr and allow deriving FromRepr for fieldless enums" rust#81642
Link: https://github.com/rust-lang/rust/pull/81642