Stream: t-lang

Topic: design meeting


nikomatsakis (Jan 06 2020 at 14:39, on Zulip):

Hey @T-lang -- just a remember that today (in a little over two hours) we have our first design meeting, discussing the pin soundness bug. Hopefully @RalfJ will be able to make it. I was wondering if anybody knows if there is a good summary that people can read to get an "overview" of the issue? (I've got to catch up, I stopped looking at some point)

nikomatsakis (Jan 06 2020 at 15:51, on Zulip):

Also, for the next two design meetings, I propose:

I'd like to have a write-up available for each of those meetings.

nikomatsakis (Jan 06 2020 at 15:51, on Zulip):

@pnkfelix and I won't be avail Jan 27, so we could cancel then.

nikomatsakis (Jan 06 2020 at 16:08, on Zulip):

For reference, the internals thread on Pin is here

nikomatsakis (Jan 06 2020 at 16:13, on Zulip):

Created a dropbox paper to take notes, as I've been persuaded hackmd is more annoying

Josh Triplett (Jan 06 2020 at 16:20, on Zulip):

I'm not going to be able to make it today; conflicting personal appointment.

nikomatsakis (Jan 06 2020 at 16:38, on Zulip):

OK. I've been catching up on the background thread but I'm finding I have some embrassingly basic questions around Pin, so I can't really setup the "general summary" I had hoped to

RalfJ (Jan 06 2020 at 16:52, on Zulip):

hi there! yes I'll make it (if Zoom works ;)

nikomatsakis (Jan 06 2020 at 16:54, on Zulip):

Zoom link

nikomatsakis (Jan 06 2020 at 17:01, on Zulip):

Hey @T-lang -- paper link

nikomatsakis (Jan 13 2020 at 17:02, on Zulip):

Hey @T-lang --

nikomatsakis (Jan 13 2020 at 17:02, on Zulip):

paper document link

nikomatsakis (Jan 13 2020 at 20:00, on Zulip):

So let's discuss upcoming design meetings. I was saying to @Josh Triplett that today's meeting was interesting. I was having doubts if it was a good topic or not, but it seemed like it was pretty useful in terms of getting everybody on the same page.

nikomatsakis (Jan 13 2020 at 20:00, on Zulip):

I think the next 2 weeks are probably not good because of hoildays / mozilla all hands

nikomatsakis (Jan 13 2020 at 20:00, on Zulip):

I'd like to be synchronizing more with some of the project groups

nikomatsakis (Jan 13 2020 at 20:00, on Zulip):

I see @Amanieu just posted Inline assembly rust-lang/rfcs#2850

nikomatsakis (Jan 13 2020 at 20:01, on Zulip):

I want to get @RalfJ and talk about the derefernceable attribute and especially the use around UnsafeCell, interactions with MMIO, not sure -- there are many angles of attack here

Lokathor (Jan 14 2020 at 04:35, on Zulip):

Was today's meeting recorded?

nikomatsakis (Jan 14 2020 at 21:21, on Zulip):

Yes, I'll be posting it shortly

RalfJ (Jan 14 2020 at 21:52, on Zulip):

I want to get RalfJ and talk about the derefernceable attribute and especially the use around UnsafeCell, interactions with MMIO, not sure -- there are many angles of attack here

yeah this has plenty of interactions at this pint

nikomatsakis (Jan 14 2020 at 22:03, on Zulip):

@RalfJ would there be some week in February that works better for you to discuss "something about that"? (we can also narrow down which angle is best)

RalfJ (Jan 15 2020 at 09:02, on Zulip):

February doesnt have anything scheduled in it, so any week should be fine

nikomatsakis (Feb 03 2020 at 16:42, on Zulip):

Hey @T-lang -- due to...lots of things last week, and then my daughter getting sick yesterday, I didn't have as much time to prepare for specialization meeting as I hoped, but I should be available in about 20 minutes as scheduled. I did review a bunch of stuff and am quickly dropping some notes into a dropbox paper.

Josh Triplett (Feb 03 2020 at 16:43, on Zulip):

Are we planning to record this meeting as we do the usual lang meetings?

nikomatsakis (Feb 03 2020 at 16:44, on Zulip):

I figured we would

nikomatsakis (Feb 03 2020 at 16:44, on Zulip):

But I'm ok either way

nikomatsakis (Feb 03 2020 at 17:00, on Zulip):

ok omw just going to grab coffee :)

Josh Triplett (Feb 03 2020 at 17:00, on Zulip):

Would be helpful, as I'm going to run a few minutes late. My apologies.

nikomatsakis (Feb 03 2020 at 17:04, on Zulip):

Hey @T-lang -- Zoom link for design meeting

nikomatsakis (Feb 03 2020 at 17:25, on Zulip):

@Josh Triplett unfortunately you're breaking up :(

Matthew Jasper (Feb 03 2020 at 21:38, on Zulip):

FWIW I'm working on adding checks for specializations in the compiler.

Matthew Jasper (Feb 03 2020 at 21:38, on Zulip):

I've also opened #68358 to remove the unsound and weaponizable impls

Matthew Jasper (Feb 03 2020 at 21:43, on Zulip):

By which I mean specializing on non-marker traits.

centril (Feb 03 2020 at 22:09, on Zulip):

@Matthew Jasper that's perfect timing :P

nikomatsakis (Feb 05 2020 at 21:44, on Zulip):

( moved some content about changes to "disarm" specialization to #t-lang > disarming specialization )

nikomatsakis (Feb 10 2020 at 16:03, on Zulip):

Hey @T-lang and others (notably @RalfJ) -- reminder that the design meeting takes place today in about 1 hour. The plan is to discuss the "derefenceable" attribute and the &T references. I've created a dropbox paper where I'm taking a stab at doing some prep work.

nikomatsakis (Feb 10 2020 at 16:06, on Zulip):

cc @James Munns fyi this may interest you :point_up: I forget if I mentioned this to you already

nikomatsakis (Feb 10 2020 at 16:06, on Zulip):

if not, um, my bad

nikomatsakis (Feb 10 2020 at 16:53, on Zulip):

Also @Hanna Kruppe, sorry for not reaching out earlier :)

nikomatsakis (Feb 10 2020 at 16:53, on Zulip):

(I did announce in an Inside Rust blog post, but I meant to do more reaching out to specific people than I did...)

RalfJ (Feb 10 2020 at 17:54, on Zulip):

@nikomatsakis what I wanted to add about "dereferencable-on-entry": of course, this is also the option that gives up most optimization potential

RalfJ (Feb 10 2020 at 17:54, on Zulip):

in the stacked borrows paper we describe some pretty impressive transformations you can do with protectors; those would be gone

RalfJ (Feb 10 2020 at 17:54, on Zulip):

how much actual performance this is about, I don't know

RalfJ (Feb 10 2020 at 17:54, on Zulip):

(I'm in the bus now)

nikomatsakis (Feb 10 2020 at 18:01, on Zulip):

@RalfJ yes, that makes total sense, and supporting those sorts of optimizations has been a long-term goal of ours

RalfJ (Feb 10 2020 at 18:01, on Zulip):

@nikomatsakis the two possible solutions we mentioned are "remove deref entirely from &UnsafeCell" and "downgrade all deref to deref_on_entry"; I'm happy to fill in some pros and cons in the paper if you put down that basic structure

nikomatsakis (Feb 10 2020 at 18:02, on Zulip):

@RalfJ ok, that would be great, I was left feeling a bit like "I don't know what the take-away is yet" after this meeting

nikomatsakis (Feb 10 2020 at 18:02, on Zulip):

I'll put down basic structure :)

RalfJ (Feb 10 2020 at 18:02, on Zulip):

didnt want to mess with you still writing ;)

pnkfelix (Feb 10 2020 at 18:02, on Zulip):

@RalfJ by the way, I've been trying to tease apart the RefMut example, and I wanted to clarify: Is your expectation that this is (today) UB, but it is a kind of UB that Miri does not catch?

RalfJ (Feb 10 2020 at 18:02, on Zulip):

(I could also imagine "downgrade deref on &UnsafeCell only", but that just mixes pros and cons from the other two so lets focus on the two extremes for now)

RalfJ (Feb 10 2020 at 18:03, on Zulip):

@pnkfelix the LLVM IR we generate for this has UB, today

RalfJ (Feb 10 2020 at 18:04, on Zulip):

(IIRC @comex managed to weaponize this even, but I might misremember)

nikomatsakis (Feb 10 2020 at 18:04, on Zulip):

@RalfJ I added some basic structure and i'm dropping in some random notes in there, but feel free to just take over

pnkfelix (Feb 10 2020 at 18:04, on Zulip):

okay. And what are you expectations for Miri?

pnkfelix (Feb 10 2020 at 18:05, on Zulip):

Let me be more specific: I'm trying to understand if I mis-translated the example, and that is why Miri is not flagging an error, or if this is a known bug in Miri, or if it a known inadequacy of the model in Miri (i.e. a "wontfix" bug)

RalfJ (Feb 10 2020 at 18:05, on Zulip):

Miri currently treats it as no-UB. in LLVM terms, Miri adds dereferencable only for plain references being passed around, not for newtypes/structs

RalfJ (Feb 10 2020 at 18:06, on Zulip):

hm actually I might be wrong about this being UB in LLVM IR... I dont know if we add dereferencable to a ScalarPair of two references...

pnkfelix (Feb 10 2020 at 18:06, on Zulip):

I see, and thus conceptually it is not allowed to e.g. move the store down, the way that it does in the original &mut example from your blog post?

RalfJ (Feb 10 2020 at 18:08, on Zulip):

this is currently a deliberate choice in Miri, it would not be hard to fix. basically Miri implements the stanza that rustc is mistranslating newtyped references.

RalfJ (Feb 10 2020 at 18:08, on Zulip):

I see, and thus conceptually it is not allowed to e.g. move the store down, the way that it does in the original &mut example from your blog post?

for the case where the reference was wrapped in a struct or tuple, yes

RalfJ (Feb 10 2020 at 18:10, on Zulip):

if y'all thinks that would be better I can make miri check wrapped references again. this is orthogonal to dereferencable vs dereferencable_on_entry.

RalfJ (Feb 10 2020 at 18:10, on Zulip):

I just realized that Retag recursing down to wrapped references made it a hell of a complicated operation, and so simplified it or else we'd never be able to formally model it in Coq ;)

RalfJ (Feb 10 2020 at 18:15, on Zulip):

@nikomatsakis I did some filling out, is that clear enough?

nikomatsakis (Feb 10 2020 at 18:59, on Zulip):

@RalfJ yes, thanks, I left one question

nikomatsakis (Feb 10 2020 at 18:59, on Zulip):

I think there was something I hadn't fully understood or considered

nikomatsakis (Feb 10 2020 at 19:00, on Zulip):

around the "infectious" nature of UnsafeCell

RalfJ (Feb 10 2020 at 19:09, on Zulip):

responded inline

nikomatsakis (Feb 10 2020 at 22:45, on Zulip):

Thanks. I had been thinking about this on a sloppy way. I hadn't fully realized that protectors give you finer grained detail than the derefenceable attribute captures. This suggests that (for this purpose) we would want "maximum infection" on Unsafe Cell but it's not obvious that this is what we want elsewhere. I guess there is a Continuum here.. the bottom line is that the unsafe cell (when acting as a ref count) is not clearly linked to the memory that it is ref counting.

RalfJ (Feb 13 2020 at 09:01, on Zulip):

yes. when they are im the same struct, we can get around this lack of "linking" by being maximally infectious (and we need to be for Arc to be fixed!), but that does not work any more when they are entirely separated somehow.

Last update: May 27 2020 at 22:15UTC