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

Latest commit

 

History

History
176 lines (137 loc) · 13.3 KB

2015-01-20.md

File metadata and controls

176 lines (137 loc) · 13.3 KB

Agenda 2015-01-20

Attending

acrichto, steveklabnik, pnkfelix, nmatsakis, zwarich, larsberg, huon, aturon, nrc

Status

  • brson: feature staging, installer updates, other junk
  • acrichto: show/string rfc, removing deprecated stuff, homu, rollups, I/O RFCs
  • pnkfelix: scoping and dtors analysis+semantics, co/invariance of Vec/Box/...

Action Items

Goodbye view items

rust-lang/rust#20179

  • acrichto: PR by eddyb to implement an RFC to reorder view items. Lifts many restrictions. The impl sounds good to me, but wanted to bring it up to make sure no gotchas. Probably don't want view items in the middle of blocks (due to shadowing), so it still has to be at the top of an expression block. But at a module level, they can be anywhere. I'm OK with this, but wanted to run it by everyone.
  • nmatsakis: Do you know whether items in a block how they interact with shadowing?
  • acrichto: Unclear. There are some examples posted, but it's a bit strange today. Keeps semantics of today.
  • brson: Did the RFC say to make items & view items the same or just reduce the restrictions on view items?
  • acrichto: In the AST they're the same.
  • brson: What did the RFC say?
  • nrc: Kinda an implementation detail...
  • brson: At one point, view items and items were separate, but then we introduced an ordering restriction...
  • acrichto: The RFC only talks about lifting the ordering restriction.
  • nrc: The ordering restriction between view items or between view items and everything else?
  • nmatsakis: What other differences were you thinking of, brson?
  • brson: extern crate before uses. But it does look like the RFC removes all restrictions.
  • nmatsakis: I could imagine thinking about attaching attributes... also, the behavior of shadowing in blocks is what I expect. You get the item up to where a variable shadows the item, and you then get the variable. But the item is in scope as if it was defined outside the block (so available even before its declaration).
  • brson: Does this fix the reason for imposing the original ordering?
  • acrichto: The problem was the old shadowing semantics, but we've disallowed that everywhere now, so we no longer need the restrictions.
  • brson: Sounds good.
  • acrichto: Will let eddyb know!

deref coercions

rust-lang/rfcs#241

  • nrc: The RFC has been merged, so I think we're done :-) It's an older RFC so I had wanted to bring it up, but it's moot since it has now been merged.

nounwind

rust-lang/rust#21186

  • acrictho: aatch had a PR because extern funs are marked nounwind. All foreign functions are now considered not unwinding, and there's now some new attributes related to unwinding / nounwinding behind feature gates. Note that if you unwind past a we abort the proces silently. What do people think about this nounwind/canunwind stuff? In terms of perf, there's some small decreases in binary sizes due to removal / merging of some landing pads.
  • brson: Because it introduces a feature, this looks like an RFC to me...
  • nmatsakis: Want to feature gate, at least for the new attributes, which you suggested as well.
  • steve: Also, do we have an RFC for putting in these things? Or for removing the gate and finishing the design?
  • brson: Once we have the feature system in place, it should start with an RFC.
  • nmatsakis: Nice to have some design first via an RFC.
  • brson: On the surface, this looks OK to me.
  • acrichto: Unwinding past an extern fn and unconditionally aborting does change semantics that aren't behind a feature gate and probably requires an RFC.
  • nmatsakis: That's undefined, right?
  • acrichto: Says that in the manual.
  • nmatsakis: Agreed. But lots of details of unsafe code are places where we do not promise backwards compatibility. C++ has similar mechanism, so this is a design space where we could probably use more thought. Aborting also seems a bit heavyweight. Also seems related to nested destructors, since destructors probably want to be nounwind? I think you want arbitrary rust functions nounwind. And generate within their own body generate a block to catch accidental panics.
  • acrichto: This is an unsafe nounwind as implemented. I don't think we'd want to inject try/catch on destructor calls.
  • nmatsakis: Bodies.
  • acrichto: Only if LLVM can optimize away. I'll comment on this to request an RFC.
  • brson: acrichto - you can shepherd

RFC shepherding for "ambitious" PRs

  • aturon: Meta-issue - somebody posted a PR that should have been an RFC over the weekend. For now, can we be proactive about shepherding that into an RFC instead of just saying, "needs an RFC."

Changes to discourse

  • brson: Today I made the IT request to turn the rust-dev mailing list off. Archive is left for posterity. Then, we'd have a new discourse for users and an internals-focused discourse (that is basically what today's is). Seems to be the best way to use discourse. Most people's concern is about splitting the community further.
  • nmatsakis: Names?
  • brson: internals.rust-lang.org. discuss.rust-lang.org will become for users.
  • nrc: If somebody posts to the mailing list, do they get a helpful not about it?
  • brson: I'll ask IT.
  • nrc: Probably friendier than bouncing.
  • larsberg: Why not just stackexchange?
  • steve: Because it's just for questions from users, not random topic discussions. Those get closed.
  • aturon: Who's going to moderate?
  • steve: I probably will by default.
  • nrc: Good to have community moderations. Reddit works well.
  • brson: Definitely can. Usual suspects will be promoted.
  • aturon: I've been a little frustrated by reddit+discuss, because if I want feedback I need to cross-post. Is there a clear story about reddit vs. discuss vs. internals?
  • brson: Others are also concerned. Reddit seems like it should be for limited-time news. Discourse is a forum for discussions. Missing that function right now. StackOverflow for Q&A, reddit for news, but nowhere for people to talk. But reddit is sort of the landing pad...
  • steve: Not a big fan of reddit because it's not consistent with our values; would rather be off it.
  • nrc: Could also make sure the cross-posts to reddit point people to discourse to discuss there. Same with RFCs.
  • huon: Could just delete all the reddit posts! A bot could comment on their posts to tell them to take it to discuss.
  • aturon: Next steps of shutting down the mailing list and moving to discourse sounds great. Can also work with the reddit mods to help them move people to discuss. This all sounds good.

discriminant intrinsic

  • acrichto: Adding an intrinsic. Lots of questions (what if you pass it a struct; pass it an enum without one, etc.). Not behind a feature gate, but in an intrinsic so definitely unstable. Curious what others think.
  • nmatsakis: Does sorta seem like an RFC candidate. Not concerned that there isn't a discriminant, but maybe this is OK? Almost think we could remove the distinction between enums and c-like enums, but that's even weirder. If deriving gets to use it, how does it avoid teh unstable thing?
  • acrichto: Nothing's using it. Pretty small. As-is, doesn't totally require an RFC. I think it would to be publicly exposed.
  • brson: THE use case here is for deriving? I hate adding features that don't have them.
  • nmtaskis: Will require some testing. Generic over any type that is an enum.
  • acrichto: If it's not an enum, this returns zero.
  • pnkfelix: Not crazy.
  • acrichto: I'd prefer an Option, but it's not a LangItem, so not easy.
  • brson: Advantages of this?
  • pnkfelix: Produces less code. There are things I was working on and coding patterns where to avoid quadratic code patterns, we map each variant to a unique number. Right now, we emit a lookup table in the generated code, which has size issues.
  • nmatsakis: I'd like to see an RFC, since even if we land this we can't use it without an RFC.
  • brson: True that deriving can't stealth-use this? Affects public interface?
  • acrichto: We could say all deriving code is omitted from stability checks. I don't know, but I think you can only derive stable traits, so not sure how it interacts.
  • brson: Think we shouldn't be hasty here.
  • acrichto: Poor aatch! That's two things being moved to RFCs...
  • nmatsakis: I know for non-zero we took a different path, but it was being used straightaway. There was an RFC, but we tabled it and make it non-publicly reachable. This feels vaguely similar to that.
  • pnkfelix: I'm inclined to agree.
  • nmatsakis: Isn't it just like 10 lines of code? Maybe an RFC would also go really fast.
  • pnkfelix: Lots of details. If this gives you back the value you associated in a c-like enum... might be some issues. But I guess the issues are with the derive code.
  • nmatsakis: Would be nice to get a small integer for building up a bitset.
  • brson: So... RFC? Or no?
  • acrichto: The non-zero thing is a good point. With zero use cases, we'd need an RFC. But I'd accept this if we have internal use cases.
  • nmatsakis: Reasonable rule to draw.
  • brson: acrichto, can you deal with this too?

Servoland

  • larsberg: nothing huge. some cargo issues acrichto is dealing with. currently upgrading rust. most major deps are done. working on main servo crates and cross targets. should be done this week.
  • brson: difficult?
  • larsberg: many mysterious errors. 'missing need additional type information on _' comes up a lot and nobody knows what to do with it. random annotations make it work. closure reform is as hard as you would expect: 'ill try :, &: mut :, ' etc. haven't generated code yet.

Issue triage

  • steve: Been doing issue triaging. Two things: 1, I tend to close lots of things, so please bring it up if that's a problem. 2, when going through the issues, I don't know how to handle one kind of issues. Things like "we want rustfmt" aren't part of the language, but not RFCs... what should we do with them?
  • nrc: The RFC repo's issues don't have to be strictly language-related. There are big library and compiler changes in there, and we should encourage it. I guess anything that's an issue that's really something that we want comments on rather than a code bug could be there. Not sure how far we want to push it.
  • pnkfelix: I always assumed that the rustfmt issue was there so community members could see them. e.g., tagged E-WishList.
  • steve: 2200 open issues is a little intimidating. Also sounds like a lot of bugs to some classes of users, who think we have lots to fix.
  • aturon: Thanks for triaging! I see lots of library requests as well, just asking for random types. It's nice to have a collection of projects, but it doesn't necessarily have to live in the rust issue tracker. Moving it to the RFC issue tracker has been positive overall, and we don't have tags at all there. Personally, I'd be in favor of moving any issues that are not actionable to the RFCs repo and we can potentially add tags there. Then point people looking for projects there.
  • brson: I like that idea. Now that we span so many repos and have so much stuff, we can't just have nice-to-haves in the current issues repo.
  • nrc: If we're going to use the RFC repo more, we should start getting stuff or we'll be in a hard place where we need to split it again.
  • brson: I do have some reservations about the RFC repo being broader than teh RFC process. Like a certain type of queue a random person in the community could do.
  • aturon: The wiki used to be a place where people had a list of interesting projects. Maybe somewhere else not on the issue tracker?
  • brson: Good opportunity to expand the scope here in terms of providing projects that grow the community.
  • pnkfelix: Put it on discuss? Or not the purpose for it?
  • steve: It's what's happened as we grow. See it in Scala, too. Mature ecosystems tend not to have this.
  • nmatsakis: Wikis and discuss are not good for tracking individual things or lists.
  • nrc: Discoverability is hard in discuss. One list pinned or lots that end up getting lost. My feeling is the easiest thing is in an issue tracker. Whether it's the RFC one or yet another, it's fine.
  • steve: I'll make a wishlist tag on the RFC repo and move them there. Lots of these things are old and just hanging out.
  • brson: Sounds good.

fott

Today I would like to nominate Barosl Lee (@barosl) for Friend of the Tree. Barosl has recently rewritten our bors cron job in a new project called homu. Homu has a number of benefits including:

  • Zero "down time" between testing different PRs (compared to 30+ minutes for bors!)
  • A new rollup button to create separate rollup PRs from other PRs.
  • Multiple repositories are supported (Cargo and Rust are on the same page)

Homu was recently deployed for rust-lang/rust thanks to a number of issues being closed out by Barosl, and it's been working fantastically so far! Barosl has also been super responsive to any new issues cropping up. Barosl truly is a Friend of the Tree!