Skip to content
This repository has been archived by the owner on Oct 9, 2018. It is now read-only.

Latest commit

 

History

History
71 lines (51 loc) · 5.36 KB

2015-02-03.md

File metadata and controls

71 lines (51 loc) · 5.36 KB

Agenda 2015-02-03

Attending

acrichto, nrc, huon, aturon, pnkfelix, brson

Status

  • acrichto: std::{io, fs, net}
  • nrc: perf, rustfmt, driver API, ...
  • brson: installer, automation
  • aturon: io stuff, RFC shepherding, API stabilization
  • pnkfelix: drop semantics, placement in/box

RFC process

  • pnkfelix: I have a pile of RFCs I'm shepherding that don't get the attention they need. If somebody wants attention on the RFC @pnkfelix is not effective - there are too many notifications. Maybe have a tag that says the RFC needs attention, could go through these tags in triage.
  • aturon: I also have this problem. Proposed solution has problems because any RFC author will immediately want attention - might just get us back where we are now.
  • aturon: We're really busy trying to get the release out; have no formal timeline for advancing RFCs; perhaps something like that would help us get on top of things.
  • brson: automatically enforce timeline with bots?
  • aturon: not sure. don't have good visibility of how RFCs have been sitting, conversations stalled, etc. systematizing the process more to create visible progress would be better.
  • nrc: in old process there was a manual process for triaging stalled RFCs. now the shepherd is responsible for identifying the ones that need effort and also putting in the effort. could have a bot check if RFC hasn't had a comment in 14 days, or add a tag.
  • nmatsakis: like bugzilla email that gives you a status update
  • pnkfelix: besides authors trying to get shepherds attention, not all shepherds can approve rfcs (not core team member). I pinged him w/o response
  • nmatsakis: if you pinged me on github that's not going to work
  • nrc: relentlessly bothering people on IRC is much more effective
  • aturon: analogous to problem of unreviewed PRs in queue. the very visible queue we have there helps. greater visibility into which RFCs are active, where they are in the process would increase pressure.
  • nrc: downside of private email is there's no public pressure
  • nrc: adapting homu to look at rfcs
  • acrichto: kind of a different model
  • brson: also agree its a different tool
  • nmatsakis: at least knowing how many days since comment would be useful
  • nmatsakis: bonus points would be some mechanism for "needinfo" like in bugzilla
  • nrc: would be relatively easy to get highfive to implement the notifications. status page is orthogonal.
  • brson: anybody want to write that script
  • nrc: I can look into it
  • brson: if we get a script for this we can host it on the build master with the others

Raw pointers and lifetimes

rust-lang/rfcs#556

  • acrichto: head's up - convention for converting raw pointers to region pointers. take a look at it. main thing is that today we constrain the output lifetime via some method, use a pointer to pointer to give it a lifetime. has downsides, so reverting to old behavior of taking raw pointer by value, which most of the time becomes &'static but it may frequently be constrained via lifetime elision now. The actual returned lifetime is still unconstrained, but we still have the type anchors for the conversions and hopefully the lifetime is constrained via elision frequently. Somewhat surprising that we're going back to something unsafe.
  • nmatsakis: big problem i have seen with transmute is transmuting to a static lifetime, often the annotations on the functions end up wrong. usually the return got a fresh lifetime which was crazy.
  • brson: is a conventions rfc right?
  • acrichto: yes. two functions whose signature will change, but conventions is that going from raw to non-raw you don't want to constrain the lifetime
  • acrichto: something that crosses a closure boundary that is send and hence 'static gets inferred but it should rather be some stack-local lifetime (a possible error that can still happen)
  • nmatsakis: let's take discussion to the RFC

Non-zeroing drop prioritization

http://internals.rust-lang.org/t/backwards-compatability-issue-with-non-zeroing-drop/1525

  • pnkfelix: we've been assuming we can do non-zeroing dynamic drop post 1.0, hoping it wouldn't break the world. Some people on IRC were upset by this claim today. main issue is that i've been focusing on linguistic issues, but claim is that people will rely on zero on drop and we can't remove it. concrete example: PriorityQueue/BinaryHeap relies on zeroing.
  • pnkfelix: haven't talked much about how to evaluate this risk, prioritize non-zero drop. nmatsakis mentioned that non-zero drop will be so popular that we might get away with it.
  • nmatsakis: haven't promised backcompat for random unsafe code. this is a tricky area, would be nice if you could write ffi bindings you can rely on, but we've identified that relying on this isn't forwards compatible. 2 reasons to up priority: this concern about unsafe code; it'll make the generated code much better.

(missed)

  • pnkfelix: mitigation: could do less zeroing
  • nmatsakis: think a lot of this code uses the attribute that let's you use the drop flag. Eh, maybe that's not true. We should feature gate that flag anyway.