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

Latest commit

 

History

History
248 lines (212 loc) · 20.5 KB

2014-09-16.md

File metadata and controls

248 lines (212 loc) · 20.5 KB
Raw

Agenda 2014-09-16

Attending

  • brson, spernsteiner, acrichto, aturon, pcwalton, zwarich, pnkfelix, steveklabnik, nrc, larsberg, huon

Status

  • brson: various windows, release process automation
  • pcwalton: Servo, landing associated items, new dtor semantics, P-backcompat-lang
  • pnkfelix: landing needs-drop analysis foundation, promoting Pre-RFCs off discuss
  • acrichto: centos 5.10, landing cargo PRs, cargo registry website
  • nrc: slicing syntax impl, thinking about cross-borrowing and inheritance RFCs
  • aturon: RFCs, num simplification, IO, stabilization prep work

Action Items

Removing GC

  • brson: On the cusp of removing it completely. Do we need an RFC for this?
  • acrichto: Servo using it?
  • larsberg: no
  • nrc: We should publicise our plan for the future.
  • pnkfelix: Yes, I plan to bring it back. One of my plans is to promote the allocator discussion from the discuss site to an RFC, which should clarify our plans.
  • brson: We've said in the past that removing language features requires an RFC.
  • pnkfelix: OK, then do you want me to do it?
  • steveklabnik: Not a language feature! It's just a library type!
  • nrc: It has compiler support, so while that's technically true...
  • zwarich: This is actually an RFC people would all get behind!
  • acrichto: I think there will be people against it, and it's a good place for the discussion.
  • pnkfelix: I'll create it.

RFC closure sugar

rust-lang/rfcs#231

  • pcwalton: This allows us to have unboxed closure sugar (Fn FnMut FnOnce to name the traits instead of |&:|). The second thing it does is splits the unboxed closure into two kinds. It seemed that people liked move |...| (though SeigeLorde likes owned |...|) for capturing by value. Otherwise, by default vars that are moved away inside the closure will be captured by value. Otherwise, they are captured by ref if you borrow them. Mutably or immutably they will be captured by type. Effectively, this makes unboxed closures more ergonomic. In particular, I'd like to see this because I'd like to land the new sugar. I'd also like to do this so we don't have to make the 'refpocalypse' change, which was many thousands of lines of change.
  • pnkfelix: You mentioned the move and owned vars syntax, but hte RFC still mentions the proc syntax...
  • pcwalton: That was universally disliked. I will update the RFC before I merge it. The biggest thing right now is that I want to make sure we can land the Trait change.
  • aturon: I think there's general consensus.
  • pcwalton: Contention is between own vs. move.
  • nrc: We should make a decision on this; the word choice keeps coming up.
  • brson: What's the impact on libraries if we take away the word move?
  • pcwalton: I don't know.
  • pnkfelix: Both a noun and a verb...
  • pcwalton: Mostly chess programs and sudoku solvers ran into it, when it was a keyword before.
  • nrc: We use move a lot, but only as part of the identifier.
  • acrichto: Compiler uses it everywhere, but that's all in borrowchk.
  • brson: We have consensus on this approach? Just need to pick a keyword? Any opposed? Then let's decide on move and go forward.
  • pnkfelix: I don't object to move... but nobody suggested proc with two bars?
  • aturon: It doesn't carry any meaning. You're just qualifying a closure with another word, but move actually has connotations for what it does.
  • pnkfelix: We're choosing a new keyword here. Would the owned choice work better in other contexts? But it seems like move would be more useful there. I think this is fine.
  • brson: We can update the RFC before it's merged.
  • pcwalton: I will. Does anyone mind if I land the trait bound syntax? It's completely uncontroversial.
  • brson: Do it.

RFC Public Items

rust-lang/rfcs#200

  • pcwalton: Makes our public items thing dumber. It doesn't try to do a global reachability search to forbid private items from being exported, but instead just checks whether the item is declared pub or not. It allows you to export things that were not reachable if they are declared pub. e.g., if the chain required going through a private module, you can still re-export it (have a function that requires it). This makes the language a lot simpler.
  • acrichto: The purpose of the RFC was to prevent private items in public signatures, but that's not what it does now - it just prevents non-pub things in public signatures.
  • pcwalton: It's just not preventing externally unreachable things.
  • aturon: This is about the def'n of privacy. Now it's just a local check. So you know if it's not marked pub, it can't be accessed externally.
  • pcwalton: The old version (reachability) resulted in very bad error messages.
  • brson: Seems like something simple.
  • acrichto: aturon's concern is solved in both approaches. If it's priv, it can't be accessed outside the module.
  • aturon: That's the concern that actually matters. The ability to name a type that users can't access isn't a big deal.
  • brson: There are some objections here. Can we represent them?
  • aturon: It just depends what your goals are. If you want to prevent ever talking about things you can't reference through a path, that's different. Niko, pcwalton, and I disagree with that.
  • achrichto: That does mean we have two different kinds of privacy. In the past, we've had lots of problems with it being tough to understand privacy. I'm not arguing for or against, but I'm worried that they don't interact well.
  • aturon: Which two systems?
  • acrichto: I can jump over private modules via pub uses. But that's separate from the pub exports.
  • aturon: I think all that's being proposed here is to limit what can be exported slightly more than we do today. Right now, when you export a function, the types mentioned in it can be any whatsoever. The change here is that they must be marked public.
  • acrichto: Three worlds: today's world, the accepted RFC, and the new RFC. This discussion is less restricted than the accepted RFC.
  • aturon: Yes.
  • acrichto: The accepted RFC does seem to take into account re-exports, etc. This revision breaks it by saying you can reach it, but you may not be able to use it at all.
  • pcwalton: I don't see the notion of external reachability the core language feature - I consider that pub vs. priv. The analysis to determine reachability is just that.
  • acrichto: What we accepted is consistent with what we have today - that the analysis determines access. This revision diverges.
  • pcwalton: What we have today has two things: who's trying to name a thing, and where does it exist in the hierarchy? But when you're trying to decide whether something is allowed to be exported, you don't have the notion of where it's trying to be called from, which makes all your rules weird.
  • acrichto: That's why the privacy pass builds up sets of what can be accessed from outside of the crate.
  • pcwalton: My argument is that results in really difficult to understand errors.
  • acrichto: That can be fixed.
  • pcwalton: I had a lot of trouble trying to implement this RFC.
  • brson: We're going in circles. How can we make progress?
  • pnkfelix: The main thing that sells me on this change is that there's local reasoning for pub vs. priv types. My question is: did you believe the other (Accepted) RFC was better?
  • acrichto: Today's state allows exporting private types. The accepted RFC prohibits all inaccessible types from leaking out. This proposed change to the RFC means you can still export private types.
  • brson: Why do you prefer reachability-based analysis?
  • acrichto: That's what the privacy pass is based on.
  • pcwalton: This is the only place where we talk (in the semantics) about "is there any path that makes this reachable?" When we talk about privacy rules right now, we talk about whether the current path is reachable. When you have a pub use, we only check locally. But the accepted RFC checks for any pub use anywhere that would allow access.
  • aturon: Should we take this offline?
  • acrichto: No, I think I'm OK with implementing this and seeing what happens.

Opt-in builtin

rust-lang/rfcs#127

  • pcwalton: Smaller delta from what we have today. This has several things in it, but I mainly want to talk about the back-incompat part. That part is that we make Copy not by default - you have to impl Copy if you want your struct copyable. This means you can now write impl Copy. Further, *T and *mut T will no longer be Send+Share, because we don't know whether they are or aren't, so it seems like the wrong default. Those are the back-incompat parts. The back-compat parts are that you will be able to say impl Send or impl Share for your own types with an unsafe declaration unsafe impl Send or unsafe impl Share to force it to be allowed.
  • acrichto: If it's inherently that, you don't need to write it.
  • pcwalton: Yes. This change is to make it less likely that people forget to make their structs sendable / shareable. You will also have negative impls, where you say that something doesn't implement Send or Share. Also define your own things like Send and Share. Not planning to implement those right away.

e.g. unsafe impl<T:Send> Share for Mutex<T> { }

  • acrichto: For the 1.0 changes, you would implement all the back-compat stuff and all the unsafe traits and impls?
  • pcwalton: Could also just hardcode Send and Share as the only things you can unsafe impl for now.
  • brson: Why are you sure we don't need negative impls? Guess you can throw an unsafe pointer in there...
  • acrichto: Would we have to keep marker types for that?
  • pcwalton: The RFC suggests keeping the marker types for convenience. Or, at least, doesn't suggest removing them. So I assume that since they're no longer needed, we could remove them. That would require a follow-up RFC.
  • brson: So the compiler would still have special knowledge of Send and Share?
  • pcwalton: Yes. It's rather low priority to add user-defined kinds.
  • brson: Requires negative impl to let the compiler not know about Send and Share.
  • pcwalton: Can keep marker types around.
  • acrichto: If we have negative impls, we can remove marker types.
  • pcwalton: Seems low-pri to remove marker types.
  • brson: We have some markers exposed publicly
  • pcwalton: Yes.
  • acrichto: We can deprecate them someday.
  • brson: Any qualms?
  • pnkfelix: We also won't add default impls, then?
  • pcwalton: Yes.
  • aturon: I have a slight hesitation on unsafe traits and impls. There are some tweaks I might be intersted in (like exact size in iterators). If we implement this, I might want to tweak the design a little bit to support that. I'm fine with accepting the RFC as-is and opening a small PR against it. Otherwise, sounds great.
  • brson: pcwalton, can you merge it?

Enum variants in type namespace

rust-lang/rfcs#234

  • nrc: I have an RFC that enum variants should be in the type namespace. It allows us to do more things with enum variants. We've previously talked about this in ??, but I wanted to pull this out and land it since it's back-incompat.
  • pcwalton: What did you have in mind? Some of the inheritance stuff?
  • nrc: It's orthogonal to that. In the future, if we want to use enum variants as part of types (which is part of one of the virtual struct proposals) that would be back-incompat because you'd get name clashes. I just want to do this to get rid of the potential name classes.
  • pcwalton: Fine with that. Just poison the type name for now?
  • nrc: yes. I discussed with nmatsakis, and he was in favor as well.
  • acrichto: STructs and enums were roughly the same before, but the following code would change. Is that OK?
// ok today, invalid with this RFC
enum Foo { Foo(int, int) }
struct Foo(int, int);
  • nrc: Yes.
  • pnkfelix: No occurrences of people using one of the enum variants as the name of the type?
  • nrc: They're listed in the RFC. IIRC, about half of them were the pattern that acrichto suggested there - enum variant and struct with the same name.
  • pnkfelix: I'm fine with this.
  • acrichto: What are we reserving this for? What are the extensions?
  • nrc: Number of thigns we could do. Simplest would be to allow a kind of refinement type, so where we know we have an AST but we have a function on a particular Node, we could just take that. More advanced is if you have nested enums, you can use any one down the nesting.
  • pnkfelix: Group together variants as a subtype of the whole thing.
  • nrc: We may decide not to do any of those, but this opens up the space for this.
  • acrichto: I'm just worried that it takes away some of the names we might want to use e.g., in the JSON parser.
  • brson: Example in the etherpad?
  • acrichto: yes...
// worrisome clashes
serialize::json::{String, Object, List};
enum Json {
    Object(Object),
    List(List),
    String(String),
}

type Object = ...;
type List = ...;
  • brson: All those things are enums with a variant after the enum?
  • pnkfelix: More that there's another type that has the same name.
  • nrc: I just made it explicit. Use json::STring instead of just String. When you see String, you don't think json.
  • aturon: Seems like a nice change to me.
  • acrichto: I think it would be OK.
  • brson: I'll merge it.

Removing I/O runtime abstractions

rust-lang/rfcs#230

  • aturon: RFC to remove the runtime system - second take on the big I/O RFC. It's a big change, and is a recent RFC, but there was an earlier one that got a lot of commentary. This is about relegating green threading to an external crate to bind more directly to native models without keeping up green threading. Explore other lightweight threading options, too. The work won't affect much of the standard I/O surface as we know it today. Community response has been positive. I'm comfortable accepting this, since we need to accept it soon. My only reluctance is that there hasn't been much feedback on the RFC.
  • brson: +1
  • pnkfelix: Sounds good to me.
  • acrichto: I expect it to evolve over time, but this is the direction we want to go.
  • aturon: Unclear how to stage this, keep Servo running, etc. but we can figure this out as we go.
  • brson: I will merge.

Collection Views

rust-lang/rfcs#216

  • aturon: Been working with Gankro on collection stuff. He has a nice RFC for improving our maps. If you look at HashMap, there's a soup of find-or-insert stuff, where you are trying to avoid a double-lookup. The APIs are kind of a mess. The RFC proposes something a bit like external iterators. It proposes getting an entry for a given key, which will return either a note about the absence or presence. You can then either insert, take out the value, or update it. This gives a natural API that looks like find+insert, but is efficient, since you get back a pointer into the map. Community response has been positive. Hesitation is just around future-proofing. Some concern about being specific to maps - do we need it for other collections? Also concern about zippers for working with persistent data structures that's quite similar. If we add persistent collections later, we might end up with an overlapping API. I think these APIs are well-tailored to maps and a clear improvement, so I'd like to land it as a starting point. Don't need to stabilize on it for 1.0.
  • pnkfelix: +1, as long as we don't stabilize too early.
  • pcwalton: I haven't read this, so I don't have any opinions.
  • brson: It's a library thing, so I'm less inclined to worry.
  • pcwalton: Agreed.
  • brson: OK. Who will merge it?
  • aturon: I can - it's not my RFC.

Parallel codegen options

  • spernsteiner: parallel codegen stuff has landed. Now I'm working on a branch to turn it on by default in some places and wanted to discuss what those default settings should be. Few different cases. It would nice to be on by default when compiling random user code. Talked with nrc about this - not having it turned on for -O2 is important because it would make us look bad in benchmarks. Have it turned on for -O and -O1 but not a large number of subdivisions to avoid big slowdowns. The most interesting case is turning it on by default for the rustc build system itself. From the numbers I have so far, turning it on with 4 threads when bootstrapping stage0/stage1 woudl be good. Can't do it for stage2 because it breaks LTO. Does this sound like it will cause any problems? Also, how will it interact with bors and the snapshot builders?
  • pcwalton: Can we get a cargo switch that uses this stuff? Since we have these two parallel options, they have to be in Cargo as well to be useable.
  • acrichto: Cargo should turn this on by default.
  • pcwalton: Worse debug info? No...
  • spernsteiner: Worse generated code, because it breaks inlining across compilation units.
  • pcwalton: Not at -O0, right?
  • spernsteiner: There is also overhead if you chop up a small crate.
  • pcwalton: Can we figure out when it's worth it?
  • spernsteiner: Maybe. I tried timings on a lot of crates from the standard distribution. The options are 1, 2, or 4 codegen units. With 2, there are a few where it slows down by a few percent, but they all build in < 1 sec anyway. For larger crates, 2 usually gives an improvement.
  • pcwalton: Maybe just the number of nodeids in the crate? So, if there's < 1000 nodeids, don't build in parallel?
  • nrc: We talked about this yesterday. If we take the default of 2, we only lose perf on compiles that are under a second anyway.
  • pcwalton: Then cargo build should just use 2.
  • brson: But we miss some by not using 4?
  • nrc: Yes, for rustc, we will want 4. Servo probably will too.
  • pcwalton: Could just correlate with the number of nodes to determine when to jump from 2 to 4.
  • spernsteiner: I'm not as confident this will correlate well with nodeid. There's some pretty strange effects from monomorph and inline. Inlines get replicated, and generic functions don't get generated anywhere. So in addition to the number of nodeids, you get big effects from the type of code you're compiling.
  • nrc: libstd is relatively large, but has lots of inling & generics so it doesn't benefits. But a normal crate probably would benefit. So the heuristcs aren't quite that simple.
  • pcwalton: We need something. Maybe just do 2 for now and optimize later?
  • brson: We're talking about baking this logic into rustc, so cargo would inherit the default.
  • acrichto: Does this give big improvements in noopt code or only opt code (for compile time)?
  • spernsteiner: For -O0, about 20% on 2 thread, 25% on 4 threads.
  • nrc: Bigger improvements for O > 0.
  • brson: In practice, people will see an improvement on debug builds and nothing elsewhere?
  • nrc: I have a proposal. For building rustc, a bare make target produces a release build, which is the slowest we can do. I'd like a bare make to do an -O2 and 4 threads. That's a good tradeoff between speed and perf. The nightlies would be -O3 and 1 thread. This would make release not the default for make.
  • brson: This is different from the proposal to only parallelize 2 stages.
  • jack: (via IRC) pcwalton, brson: I guess you can't hear me, but this seems like something a crate could opt into with a crate attribute. if parallel code gen is used, the preferred parallelism level.
  • spernsteiner: For release builds, only the first of the three phases can be built in parallel, since some of the stage2 stuff is released.
  • nrc: We should make a more detailed proposal, but if there are no principled objections to a non-optimal default...
  • brson: This does play into some of the automation changes I'm making, so we should continue this offline.