- fott (brson)
- Servo - servo/servo#2853 (larsberg)
- homu (acrichto)
- I/O RFCs (acrichto/aturon)
- overflow rust-lang/rfcs#560 (nmatsakis)
acrichto, nmatsakis, brson, pcwalton, larsberg, pnkfelix, huonw, aturon, zwarich, nrc, steveklabnik
- brson: feature staging, installer upgrades, misc automation mentoring
- pnkfelix: landing scoping/dtor reform
- acrichto: updating cargo/crates.io/crates
- aturon: moving forward on IO, rolling out path, conventions issues
- nrc: highfive, DXR, deglobber
- nmatsakis: deicing, writing about orphan rules
Seonghoon has been an active member of the Rust community since early 2013, and although he has made a number of valuable contributions to Rust itself, his greatest work has been in developing key libraries out of tree. rust-encoding, one of the most popular crates in Cargo, performs character encoding, and rust-chrono date / time handling, both of which fill critical holes in the functionality of the standard library. rust-strconv is a prototype of efficient numerical string conversions that is a candidate for future inclusion in the standard library. He maintains a blog where he discusses his work. He's super cool.
- acrichto: Heads-up that homu is a rewrite of bors by barosl that's more evented. It removes some of the cron job delays. I've been using it on Cargo for a while, and getting rid of some of the delays. Planning to roll this out over the next few weeks. The biggest change is that r+ is different.
- larsberg: How does this relate to taskcluster work?
- brson: That wouldn't happen for a while, and probably incremental.
- nmatsakis: (mumble) Was going to say we had basically converged, but there are still a few pending comments. Gist is that we will check for overflow & underflow and some other anomolous behavior (bad shifts) in debug mode, but disable it by default for optimized code. Reasoning is that checking at least some of the time catches places where you intended to do wrapping, though it's not a cure-all. For that, you might want another tool. Gives us the room in the future to make the checks on all the time by default. Because it's on in debug, it does make sure that we can make changes to optimized builds in the future. There were some points of clarification, etc. on the RFCs we're still working through. One question is: what should the behavior be if we DON'T check - what do we provide? The original said an undefined value if it doesn't panic. Arguments are that it should wrap in the RFC. Seems minute, since that's what would happen anyway. I do like at least slightly defining the behavior.
- brson: Overflow semantics impact autovectorization.
- nmatsakis: Autovectorization does wrap, so it doesn't interfere. But if there were other cases (e.g., saturating instructions), you might want to do that.
- zwarich: LLVM has support for vectorizing saturating operations where supported. SSE has some; neon has others. It will recognize the idiom already.
- nmatsakis: More conservative? Doesn't introduce saturating operations.
- zwarich: Yes, LLVM would never do something like that.
- brson: Does this decision affect shifts?
- nmatsakis: I put in that we should check if the number of bits is out of the legal range, as it's another case where we've had some debates. One question is if you shift left and lose bits, is that an overflow? I did not say it was.
- brson: Debug only?
- nmtaskis: For whenever overflow checks are enabled. I feel like bitshifting is that and not math, but I can see the other argument for people who've been strength reducing by hand.
- pcwalton: Related: what happens when STATIC overflow. Or shifting by more than the length of a type...
- nmatsakis: That's in there.
- pcwalton: There's a good reason for making it undefined - it's Intel vs. PowerPC issues. Intel shifts off the last five, but PowerPC shifts off the last six. They and by a different bit pattern.
- nmatsakis: I am pretty happy with the checked variation compromise.
- larsberg: Planning to increase the automation so you'll have debug builds to run tests on for rust?
- nmatsakis: I don't have any plans at that time.
- acrichto: Yes, we will. We do not test optimized + debug checks. Just optimized and unoptimized. No NDEBUG/!NDEBUG.
- huonw: Leaving it in unoptimized seems like it leaves room for changing the optimized behavior if h/w improves.
- brson: All the things we do here give us room to make changes in the future, right?
- nmatsakis: Yes.
- aturon: I like this direction. Coming out of the int discussion, I realized that overflow are less common than underflow. I also like being more explicit about when you want wrapping semantics via different types or operators.
- acrichto: Some of the criticism is just around the prose of the RFC.
- nmatsakis: Few more things to handle. e.g.,
INT_MIN / -1
- Lars: Not a ton to say. We've prepped a snapshot, but haven't started rolling out the alpha build yet. There is a problem from the previous upgrade related to CowString + Channels, seeming bug. We've switched to String.
- nmatsakis: The Cow from std? Doesn't that involve borrowed data? Seems problematic to Send.
- larsberg: I think we probably have corruption elsewhere causing this problem.
- nmatsakis: I'm surprised it's even allowed.
- acrichto: We took the big I/O RFC after trimming it down to bare-bones. Lots of sub-RFCs for individual sections.
- aturon: After 200+ comments, discussion had come to a standstill, so this is an effort to land pieces of it independently. If you haven't looked at it, I'd love for you to do so and jump in on the comment threads!
- brson: Six weeks to a potentially-Rust-1.0 build! Everybody should be pretty heads-down and know what they're doing...
- nmatsakis: Any prioritizing / triaging required?
- aturon: We now have both Beta and 1.0 milestones. Distinction is that Beta is the stuff we definitely need in the next 6 weeks and must be in. Stuff in 1.0 is polish work that we'd really like to have but maybe could do later as minor fixes in the Beta branch. Got halfway through the nominated tickets last time.
- brson: Might assign everything in the 1.0/Beta milestones.
- aturon: If you're working on something important for Beta and it doesn't have an issue, you should make an issue and nominate it.
- steveklabnik: I have an RFC that's been open for a long time, about comment style. Maybe now is the time to talk about them, for rustfmt purposes? How do I move this along?
- nmatsakis: I guess move on it?
- brson: If it's fresh & relevant, you can get everybody to say 👍 and merge it.
- aturon: Is this pretty orthogonal to other questions?
- steve: I think the style RFCs will be giant bikesheds overall, so I'm trying to do small ones.
- aturon: Been tough to make progress because the pieces need to fit together (e.g., reducing rightward drift). Beta might be a nice time to nail this down, but if people have thoughts, please let us know.
- larsberg: Please have a tool so we can try these out! I need to see how it impacts Servo's codebase to know whether I violently disagree with guidelines or not.
- pcwalton: olson had an early rustfmt tool
- aturon: Maybe we can find people in the broader community to help with the tool.
- steve: one of the most common comments on reddit & HN. Be nice to have a base tool for people to extend rather than asking them to start it from scratch.
- nmatsakis: rustfmt is indeed often requested. I could even imagine automatability would be a factor in the style guidelines.
- steve: I'll put a rustfmt on crates.io...