Libs Meetings
Minutes
Meeting Link: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
Attendees: Amanieu, Josh Triplett, Mara, David, Chris Denton, The 8472, TC, loudjanilef
12 rust-lang/rust T-libs-api FCPs
scottmcm (1), BurntSushi (9), dtolnay (1), m-ou-se (7), nikomatsakis (2), jackh726 (1), Amanieu (5), joshtriplett (8), compiler-errors (1), thomcc (1), the8472 (1)
We previously rejected this.
Amanieu: After discussing at the all-hands, i think we should reconsider. I was the main person against this.
Amanieu: My main concern was that this'd be the start of a slippery slope towards more and more nul-terminated strings for C++ users.
Amanieu: But I think there's sufficient motivation for this.
David: Do they need a separate signature? Or just a guarantee that there's a nul byte after the slice?
Amanieu: Separate signature. I think that's strictly better.
Amanieu: From the LKML:
But more importantly, this is really a Rust problem. Does Rust really
have no NUL-terminated strings? It should hide them in shame and
construct proper, robust strings, instead of spreading this disease to
the rest of the kernel, IMHO …
Amanieu: anyway, should we have nul terminated file locations?
Mara: Fine with me. Doesn't really cost anything and seems useful in plenty of cases.
JoshT:
Amanieu to reply and accept.
JoshT: Considering the response to our request, with no examples.. it seems like this should stay a third-party thing for now.
TC: What happened after it was approved and now?
Amanieu: We approved when we thought it could return a regular guard. But that doesn't work. At the time you acquire the initial read lock, you need to get a guard that is invariant instead of covariant. This blows up the API surface.
Mara: Sounds like something to experiment with in another crate first.
Amanieu: Maybe first add to parking_lot, then come back.
TC: What about 'try_upgrade' in parking_lot?
Amanieu: That's a very different one.
Amanieu: Let's first add it to parking_lot.
Amanieu to reply.
JoshT: for overflowing_signed_diff, when would it ever be useful to have the value when the bool is true?
Amanieu: saturating_signed_diff and overflowing_signed_diff don't appear in rustdoc..
Amanieu: Let me update the tracking issue.
TC: Since this is basically the integer version of offset_from_unsigned
for pointers, should we align the name in any way?
Amanieu: No, these are just integers.
Amanieu: I'll start FCP.
FCP finished. Should be merged?
JoshT: https://github.com/rust-lang/rust/pull/141312
Amanieu: removed label
Nominating because people want to bikeshed the module (arch
) and name (breakpoint
).
JoshT: For core::arch, it'd be the only function directly in it. We ruled out core::process before, but that's still suggested now.
JoshT: any objections against core::arch?
Mara: seems fine, don't have strong opinions. object against core::process.
JoshT: Second, name breakpoint
. might suggest it's an breakpoint that does nothing when no debugger attached, rather than something that always breaks/signals.
TC: That'd make more sense in core::hint.
Mara: Would it be bad if we ended up having both arch::breakpoint and hint::breakpoint?
JoshT: Not at all.
JoshT: hint::breakpoint would live in std. maybe call it breakpoint_if_debugging() or something.
TC: In that case, I'd expect it in core::hint, and have the debugger have support for that rather than std figuring out if there's a debugger.
Mara: The tracking issue discussion seems to mix up 'arch::breakpoint' and 'hint::breakpoint'. The first should just be an easy way to write the bkpt
instruction or equivalent on whatever platform you're on. So that would should go in arch
in any case.
TC: I buy that.
Mara: Regardless of what we put in any potential core::debug, I'd still want the instruction in core::arch.
Amanieu: Also core::arch::trap
. Makes sense in core::arch.
The 8472: Does wasm have a breakpoint instruction?
Amanieu: It has 'trap'. breakpoint can fall back to trap.
Mara: In liballoc's Arc, we already use core::abort, even though it's not exposed yet. trap instruction.
The 8472: Couldn't we say that fallthrough is a valid implementation?
Mara: That's what happens if you continue from the debugger.
TC: If we say that fallthrough is a valid implementation, then could we make it a const function?
Mara: No. It's an architecture specific instruction. core::arch is just slightly higher level inline assembly. Maybe the hint could be const.
Amanieu: Clearly there is no debugger attached during const eval, so it could theoretically be. But that may not be desirable.
Amanieu: Let's defer this till next week.
In FCP, unnominated.
In FCP, unnominated.
Mara: thread locals need fixing in many ways.
The 8472: Shouldn't unmovable things be pinned?
Amanieu: These are statics..
David: Can't we drop it in place?
Amanieu: That can be unsound. The destructor can access the thread local again.
Amanieu: This can probably be fixed. Probably doable.
Mara: Just be careful. This has gone wrong before. There's some comment somewhere with some warnings.
Mara: Let's fix it and keep it a few releases before guaranteeing.
Amanieu: Interface of char and integers is different. So this makes the NonZero wrapper more complicated.
Amanieu: Actually, the integer methods are implemented directly on the specific NonZero<u32>
etc types
Mara: PR feels incomplete. Doesn't add any methods for NonZero<char>
..
The 8472: Motivation also feels incomplete.
David: new
and a few others are implemented for all of NonZero
.
Mara: Is that enough? Does that make for a complete enough initial api?
Amanieu: Yes. enough for just storing stuff.
Mara: Alright. Seems fine to me. Maybe some more motivation, but I'm easily convinced.
(Skipped.)
Waiting on author.
Counterproposal: text.as_ascii().unwrap().chunks(N).map(<[AsciiChar]>::as_str)
The 8472 to reply
We wanted the word "resolve" in the method name, and we wanted it to canonicalize the returned path. Otherwise we were leaning toward happiness with it.
Chris is going to reword the ACP based on this feedback.
TC: We have a lang nomination that's similar to this in some ways:
https://github.com/rust-lang/rust/issues/140803
The 8472: In terms of the guarantees made by the trait in this ACP, we'd want to ask lang.
The 8472: In terms of the CFI discussion, any outcome of that discussion would also be relevant here, in terms of how this would interact with CFI.
TC: In terms of extern types, t-types is FCPing the part of the impl of hierarchy of sized types needed to unblock this:
https://github.com/rust-lang/rust/pull/137944
We're discussing Amanieu's proposal for this here:
https://github.com/rust-lang/libs-team/issues/589#issuecomment-2895919811
TC: This seems like generally the right shape to me.
Amanieu: One question is whether we'd ever want to support function pointers of different size than data pointers.
TC: Does CHERI need anything like that?
Amanieu: No; they have pointers that are differently sized than usize
, but the function and data pointers are the same size.
Generated by fully-automatic-rust-libs-team-triage-meeting-agenda-generator