pnkfelix: Compiler team has a bot that links threads to Zulip. The meeting issue for lang-team#181 had a fair bit of technical discussion. Should we consider doing something similar?
joshtriplett: I thought we did link threads to Zulip
nikomatsakis: I think not for meeting proposals
joshtriplett: as a general rule, Zulip seems preferable, but there's a certain overhead of weirdness to "don't talk here". Makes some sense for things where large quantities of discussion are expected. For meeting proposals, mean/median case has been approximately no discussion, in which case GH seems fine.
pnkfelix: I'd prefer to think about constraints that are appropriate. For RFCs, it's a feature that we invite communication from arbitrary people, so we deliberately make RFC comment thread accessible.
joshtriplett: True, and we've also observed it sometimes is low value, but I appreciate point you're making. Zulip trade offs convenience of platform/reading/interacting and is less accessible to a broader audience.
pnkfelix: I guess point is which space is appropriate to a lang team meeting proposal.
tmandry: just for consistency, let's argue for that?
joshtriplett: sure, but can automated message have a clear exception for "scheduling discussions" (i.e., what time is the meeting). Let's make sure people feel those messages can still go to GH, not just to Zulip.
nikomatsakis: we should encourage that GH thread to be a summary of key details, so e.g. link to hackmd and scheduling data.
Action Item: Felix will look into enabling the bot to do the posting
None.
None.
dyn Trait values" rfcs#3324Link: https://github.com/rust-lang/rfcs/pull/3324
nikomatsakis: oh bother. I said I would do this last week. Will try to do it this week.
Action item: Niko to do it.
Check your boxes!
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
- @compiler-errors
- @cramertj
- @jackh726
- @joshtriplett
- @lcnr
- @nikomatsakis
- @oli-obk
- @pnkfelix
- @scottmcm
- @spastorino
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
@rfcbot merge
This has been under discussion for some time! I am excited about seeing this team get started.
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @cramertj
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
Shall we stabilieze the
extern "efiapi"calling convention?@rfcbot merge
#![feature(target_feature_11)]" rust#99767Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @cramertj
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
@rfcbot merge
c"..." string literals" rfcs#3348Link: https://github.com/rust-lang/rfcs/pull/3348
Link: https://github.com/rust-lang/rust/pull/103877
None.
Link: https://github.com/rust-lang/rust/pull/105085
motivating example:
fn main() {
let _ = &&(NoisyDrop("drop!"), 0).1;
// NosiyDrop is not dropped ...
}
Breaks 1 crate (and that crate makes heavy use of nightly)
nikomatsakis: I agree with Oli's assessment:
This is obviously a bug, as the user did not ask for promotion and we should not silently promote away side effects like dropping.
pnkfelix: yeah.
tmandry: seems like something we should fix, any idea when it was added?
nikomatsakis: I would guess a long time, promotion code has been getting more conservative over time.
joshtriplett: FCP?
nikomatsakis: +1, DO IT
Link: https://github.com/rust-lang/rust/pull/102318
joshtriplett: This was FCP'd 2 years ago, so do we need a new one?
pnkfelix: Are you sure previous FCP was t-lang, not t-compiler?
simulacrum: My perspective on FCPs is that we are capturing state of the world at that point. It seems like state of the world has changed in the past 2 years.
joshtriplett: Valid. If anybody would rather do another FCP we can, but arguably the case we made a decision on was the semantic change to the language, and that hasn't meaningfully changed, there was a quality of impl problem. But quite happy to start an FCP.
simulacrum: I'm saying lang has changed, though I doubt it affects decision in this case
nikomatsakis: I agree with Mark, decisions from 2 years ago that never took place shouldn't be presumed to hold, though I don't see any change in this instance that matters (and maybe )
tmandry: what is behavior without attribute?
joshtriplett: previously it would abort, but now it panics, which means if you're careful, you can potentially catch it
tmandry: this would affect most Rust programs today
joshtriplett: In practice, no… on linux, you'll not see this because it overallocates. Might see it on Windows, not sure about Mac.
simulacrum: tracking issue suggests behavior with std is not changed. If std is linked in, the allocator handler exists, and it aborts, as it always did.
joshtriplett: Oh? I had impression that wasn't true.
simulacrum: If not, we should not FCP, and rather update docs.
joshtriplett: Ah, I see…
rapid typing by pnkfelix to confirm whether allocation handler still exists for std today
joshtriplett: It does! Programs that lnk std would not change. Separate question of whether std should change its own error handler.
pnkfelix: right, main goal is enabling nostd+liballoc to run on stable.
Link: https://github.com/rust-lang/rfcs/pull/3318
y86dev: Has been nominated for quite a while. I still think it needs some time cooking. Current proposal is complicated but haven't found a simpler one. Consensus is it needs to bre improved, but is there any general guidance for what direction? Projection in my current view should be as general as possible. Does everybody know what projection is?
joshtriplett: I nominated this to get a "direction check".
y86dev: to me it seemed useful for pin-projection, cell types (which currently requires unsafe ptr manipulation). Operation is actually safe, since if you have a Cell around a type, each field is also essentially in a Cell.
nikomatsakis: design meeting discussion?
tmandry: we read this in the async WG. I can share a link to the notes. Does require some time to steep in the RFC text.
y86dev: For pin, we also need to handle pin-drop issue, if you're familiar with pin-project, you can't implement Drop on a projectable struct, because in the drop method you have access to &mut self, unsound if you're pinned. We'd have to have some workaround. I also wanted to support general unwrapping, so if you have Pin around a struct type, and a field which is not structurally pinned, you can directly access the field, removes the wrapper – to add that in a general way often requires an elaborate API around it.
tmandry: reminds me of another proposal, coming out of the C++ interop use case, generalization of deref to allow things like raw pointers. Essentially to do autoderef for method invocation. Allow them to be self types. Let me try to find it.
pnkfelix: note that the RFC was rewritten after the async WG meeting.
…
joshtriplett: sounds like we want to de-nominate for now and it sounds like people should take a look and get an idea of what they think of it.
tmandry: Link for Receiver trait proposal, discussion
y86dev: Seems orthogonal from projection concerns.
Link: https://github.com/rust-lang/rust/pull/103735
nikomatsakis: Comment after last week – unclear if this should still be nominated, seems like no?
Conclusion: remove nomination and request re-nomination if there is some specific question.
Action Item: pnkfelix to do that
Link: https://github.com/rust-lang/rust/pull/103413
nikomatsakis: This seems right to me. Procedural step? Actually no, I think the correct rules are:
Another way to put it:
PhantomData values to be droppedAction Item: Niko and Felix to follow-up and determine who will leave comment (and who will do experimental analysis, who will consolidate the findings/theories fo comment thread, etc)
Link: https://github.com/rust-lang/rust/pull/97373
briefly reviewed and verified there is a test, removed nomination
tmandry: should we have a Cell<Seld> test?
Link: https://github.com/rust-lang/rust/pull/104429
comment:
https://github.com/rust-lang/rust/pull/104429#issuecomment-1319499278
joshtriplett: These traits are not unsafe to derive, wouldn't let you write these impls without an unsafe block normally, but that's not fundamentally a problem.
pnkfelix: Right, as we control the impl.
joshtriplett: Another proposal going around for unsafe attributes, idea being that to apply certain attributes, must write unsafe in the attribute.
nikomatsakis: maybe but it feels like declared the packed unsafe, still seems valuable to have to vet uses of the fields
some cases that work today will no longer work:
If you have a packed struct that derives builtin traits, and it contains fields that aren't Copy, and none of its fields are unaligned, then that would work with the old approach and not work with the new approach. Note that in such a struct the packed attribute is not actually changing the layout. (This is the "pretty strange" case mentioned earlier.)
Comment: https://github.com/rust-lang/rust/pull/104429#issuecomment-1319499278
#[repr(packed)]
#[derive(Eq, PartialEq)]
pub struct FlexZeroSlice {
width: u8,
data: [u8],
}
Ralf's dear Rust-lang latter: https://github.com/rust-lang/rust/pull/104429#issuecomment-1320909245
nikomatsakis: special-casing u8/[u8] seems like an ok special case to me to avoid breakage
joshtriplett: if we just look for u8 and there is some type shadowing u8 in scope…
nikomatsakis: …good point, we don't have name resolution results. That means you could get bad compilation errors. Example:
#[repr(packed)]
#[derive(Eq, PartialEq)]
pub struct FlexZeroSlice {
width: u8,
data: [u32],
}
fn main() {}
…fails to compile today.
joshtriplett: but even with that case, this will still break some code?
simulacrum: I think the argument is that icu4x is widely used, whereas the others are not.
nikomatsakis: this seems like something we should do over an edition.
joshtriplett: doesn't seem like something where new feature is so eagerly needed, it can't wait
nikomatsakis: would love to see this over an edition with some eager opt-in you can do today
tmandry: I think that would be fine; icu4x isn't that widely used, they just realized 1.0 recently, 58K downloads?
simulacrum: fair, but more widely used than a random crate
pnkfelix: comment thread did say something about how the icu4x case– what they really want is an assertion that it's packable, want to make sure it doesn't have padding injected, they want a layout assertion
MaybeUninit::uninit().assume_init()" rust#100423Link: https://github.com/rust-lang/rust/pull/100423
Link: https://github.com/rust-lang/rust/pull/104616
instruction_set inlining restrictions" reference#1307
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe