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

Latest commit

 

History

History
169 lines (134 loc) · 13.8 KB

2014-07-29.md

File metadata and controls

169 lines (134 loc) · 13.8 KB
Raw

Agenda 7/29/2014

Attending

cmr, spernsteiner, luqman, brson, larsberg, aturon, pcwalton, zwarich, pnkfelix, acrichto, azita, nmatsakis, huon

Status

  • brson: windows, automation, admin, optimization
  • pnkfelix: nonzeroing drop
  • acrichto: cargo freshness, cargo lockfile, cargo-{upload,login}
  • aturon: library stabilization, rust-book, concurrency utils, associated item design, collections
  • pcwalton: P-backcompat-lang; specifically lifetimes escaping in traits, new destructor semantics, and unboxed closures
  • nmatsakis: #5527, #5723-ish

Action Items

Friend of the Tree

Björn Steinbrink (dotdash)

Contributing since April 2013. Björn has done many optimizations for Rust, including removing allocation bloat in iterators, fmt, and managed boxes; optimizing fail!; adding strategic inlining in the libraries; speeding up data structures in the compiler; eliminating quadratic blowup in translation, and other IR bloat problems.

He's really done an amazing number of optimizations to Rust.

Most recently he earned huge kudos by teaching LLVM about the lifetime of variables, allowing Rust to make much more efficient use of the stack.

Björn is a total FOTT.

Target specs RFC PR 131

  • cmr: move hardcoded knowledge about target-specific compiler settings into a json file. Lets people invent their own triples. There's lots more to handle than in this RFC, but it's more of the same..
  • brson: There are just more configuration items that need to be part of the system?
  • cmr: yes
  • acrichto: Will today's have their own, or leave them hardcoded?
  • cmr: more consistent to not hardcode
  • brson: but then we have to worry about locating that file
  • brson: can start with leaving the current stuff hardcoded?
  • acrichto: seems fine

Removing borrowck knowledge of Box

  • zwarich: Implemented this change, lists all of the places we needed to make changes in the standard distribution as a result. Only 5 changes, only 2 were even slightly invasive, and one will go away with nonlexical borrows, and the other would go away if we switched to a CFG-based implementation of codegen. I'm for the change, think we should accept it.
  • brson: Results sounds good to me.
  • [general agreement]

RFC PR 155

  • brson: Requires putting impls next to types. Basic idea is that resolve has bugs that makes not doing this weird. Clamp down on this to be on the safe side.
  • acrichto: I think the plan is that if we were to accept this, ...
  • nmatsakis: ... my point is that we'll revisit this to extend what we do. It will be a superset.
  • felix: General concern about whether to feature gate before we remove.
  • nmatsakis: Can also work around this change by introducing traits.

RFC PR 148

  • pnkfelix: Reactions to changing < to [ in types?
  • pcwalton: I like that we look like C++
  • zwarich: This could be important for macros because of the inability to match < and > into token trees.
  • nmatsakis: I feel like [] is better but <> is what we have, and it's a lot of work to change. Hard to justify.
  • pcwalton: But macros don't need to look like types
  • pnkfelix: You may want to be able to parse a type in a macro, though
  • ... some discussion about token trees ...
  • pcwalton: You could possibly have some way for macro to restructure token tree into a new tree shape by specifying that < should be matched
  • zwarich: Don't you still have problem when trying to generate token tree up front that some macro that looks like a type parameter list might have expressions in it, and one of them might be a comparison or shift operator?
  • pcwalton: Idea is that thing that parses macros doesn't create tree structure yet, but it can be imposed later by macro def'n. (approximated - nmatsakis)
  • zwarich: assuming token tree itself is not delimited by angle brackets
  • pcwalton: yes
  • zwarich: should make specification more complicated
  • pcwalton: yes, but no great challenge
  • brson: C++ has specified more complicated things
  • nmatsakis: I feel like we should move to something else
  • brson: We've long had a policy not to reverse this decision because it's just too much trouble.
  • pcwalton: If you want someone to blame, blame me, I did this 3 years ago

Servo update

  • lars: We have 2 high priority bugs for servo. Alex has started working #16060, hang on OS X. We've worked around it, was blocking our upgrade. That other one we just added, kmc has problems with capturing self in his HTML parser. That's getting close to landing. #15750
  • [discussion of details]

Removing variance-sensitive rule in lifetime elision

  • pcwalton: There's a rule about it not doing lifetime elision for covariant positions. But determining that is a global analysis that requires types to be complete etc. To implement this we need to .... entirely new pass in typeck, and this rule happens... never.
  • aturon: We discussed this a bit last week. I'm fine with this. When we were designing the RFC we weren't quite sure how to handle covariant lifetimes so we took the conservative approach of "don't apply elision", but I'm fine with uniformly applying the elision.
  • brson: Can changing this cause [errors]?
  • aturon: At worst your function will fail to compile against the elided signature and you'll have to annotate.
  • zwarich: Currently covariant lifetime parameters are very uncommon in general, if it turns out that as people write different kinds of software in Rust, can we change the behavior?
  • [details, only about warnings/error messages]
  • pcwalton: There is a procedural issue here, I think post-1.0 we should take the linux kernel approach where they break userspace if there isn't any applications it would actually break.

Bindings after @

  • pcwalton: We had a safety issue with rvalues in borrowck. Was only a problem with @-patterns and bindings on both sides. I tried to fix this the right way and got a lot of borrowck errors that seemed pretty fundamental. Seems the simpler thing is to just forbid bindings on both side. Can write a @ Some(_) but not a @ Some(b). So, I removed it. We can add this back if we find a way to handle this in borrowck.
  • [details]
  • niko: My opinion is that I think this should work but given how little code is affected I think this is just what we should do for the time being.

RFCs (https://mail.mozilla.org/pipermail/rust-dev/2014-July/010946.html)

RFC PR 136

  • brson: Discussed this last week. Don't recall why we went around on it again...
  • aturon: I wanted more time to look at it, which I did.
  • [explanation of the problem, from the RFC]
  • aturon: I think this design is more or less accidental. I think the practical ramification of this state of affairs is that if you want to refactor code, you know that if something is private you can't break anything else. But that's not true, at least not locally, because the private type can be leaked elsewhere in the API. RFC proposes to close this hole. I feel like the current design is not a really well thought out, seems like this RFC presents a conservative approach and we can do it in a more comprehensive way later. People are abusing this in various ways today, however.
  • brson: Last time we talked about this a long time ago, we didn't want to fix this because we didn't have a technical means to actually close this hole. Does this seem solvable?
  • niko: I feel like part of the argument before was that privacy wasn't providing ... the usual ownership type argument of "privacy isn't enough". I guess I don't remember if there was a specific hole... my feeling has been that privacy itself is a sort of lint. I'm not ready to say yes. One question I was thinking about: right now all enum variants are public, and if you want an enum with a private variant you could do this very easily by making a private struct and embedding that in the variant.
  • aturon: I'm not necessarily opposed to all leakage, I just think we should have a clear design.
  • pcwalton: I think we should be careful that we keep getting closer and closer to this but never actually get there. If we keep trying to plug more and more holes with ad-hoc rules, ... In terms of a coherent design, I think a design that solves 70% of the problem may be more coherent than a design that solves 95% of the problem but is 10x more complex. I don't know if this applies here, but I'm cautious.
  • niko: I think our current rules are very based on "when you write a name, there are restrictions on the names you can write". The weirdness in my mind isn't that you can access public fields of a private struct, but you can let a type be inferred that you can't type yourself. It's not clear to me that we want the whole package. Private supertraits seem to be useful (and harmless), but maybe fields are not, or types with variables after inference must be accessible, or the types of rvalues, etc.
  • felix: I'd like to interject here that one of the suggestions is that if we make this change, at least two people are suggesting putting in a feature gate for this, because until we have abstract types, people want to get the effect.
  • niko: We have too many feature gates!
  • pcwalton: I think the current case where we have a lint is strictly better than an error + feature gate.
  • felix: The problem then is that we need to continue to support the current rules. while if we were to feature-gate our current behavior (and adopt the proposal from this RFC as the default without the feature gate), then that gives us the breathing room to find a better solution later (e.g. implementing proper abstract types).
  • pcwalton: To me, conservative means we could be more accepting, because then we have simpler rules that we apply consistently, which we can then tighten up later.
  • niko: Can someone explain what the abstract type thing is?
  • aturon: [explanation that cmr didn't really catch]
  • aturon: They'd rather use newtypes, but it's harder.
  • brson: I think this is a pattern we want to wean people off of, this sounds crazy.
  • aturon: Right, I think we want to make newtypes more ergonomic.
  • brson: It seems that there are some rules we could apply here, that fix the worst of this problem, and is both conservative and practical.
  • zwarich: This is a stupid question since we don't have this feature yet, but how does typeof interact with this name privacy thing? If I use typeof, I can make types, [...]
  • nmatsakis: I don't understand how they interact, [...]
  • zwarich: I mean with our current behavior. If you have a function declaration, [...] with typeof, you can create a name for a type you shouldn't be able to name.
  • cmr: From my perspective, I want to reduce the API surface of my libraries, [...]
  • niko: Is there a problem with just implementing this?
  • [... details that cmr missed ... ]
  • brson: Are we in a position to make a decision or do we want to continue thinking about it?
  • pcwalton: punt
  • brson: punted.

Unboxed closures

  • niko: Some of the implementation is done. Aaron and I had a brainstorming session where we determined we could do some significant ergonomic improvements that isn't in the text of the RFC. Determined we could figure out how to capture on a variable-by-variable bases and how self should be treated. Patrick wanted to talk about the tupling of arguments. Might want to add a feature gate on referencing behavior that exposes the tupling. Otherwise, I think it's up to date.
  • brson: This RFC has been percolating for a while,
  • niko: I think we can accept it, but there are still some changes.
  • brson: Everyone onboard with going forward with this?

Opt-in built-in traits 2

  • niko: For various reasons I think we made the wrong call with the details in the previous OIBIT RFC, thus this version. I've proposed an alternative that adds some language features that lets us take Send and Share out of the language and move them into the libraries. This is the last place the language is connected to our threading model, if I'm not mistaken. First, it lets you declare a trait is unsafe, which makes implementing it unsafe, indicating that unsafe code depends on the guarantees of this trait. Then add a recursive [...] that lets you say "This trait is implemented for all types that don't reach something that opts out". And things can opt back in by implementing the trait.
  • cmr: And opting back in is an unsafe impl?
  • niko: Yes, the idea is that normal Rust code doesn't care about it, only need to opt in if you're doing unsafe things.
  • brson: Any changes to Copy?
  • niko: No, inheriting that behavior from the other RFC. With this the only traits builtin to the language is [...].
  • brson: One minute left... thumbs up? Out of time.
  • huon: Presumably the information that is inherited from the other RFC should be in the RFC, since this is the text that will be around forever.
  • niko: I agree.