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

Latest commit

 

History

History
186 lines (144 loc) · 14.4 KB

2014-11-11.md

File metadata and controls

186 lines (144 loc) · 14.4 KB

Agenda 2014-11-11

Attending

brson, acrichto, steveklabnik, pnkfelix, aturon, pcwalton, jbclements, zwarich, kmc

Status

  • brson: dist syncing, other automation
  • aturon: path RFC, collections reform impl, next stage of Runtime removal, conventions rollout
  • acrichto: crates.io launching, TLS, cargo build cmd cleanup

Action Items

Friend of the Tree

I (nmatsakis) would like to nominate Brian Koropoff aka unwound aka rewound as friend of the tree. In the last few weeks, he has fixed many, many tricky ICEs all over the compiler, but particularly in the area of unboxed closures and the borrow checker. He has also completely rewritten how unboxed closures interact with monomorphization and had a huge impact on making them usable. Brian Koropoff is truly a Friend of the Tree.

std::fmt

rust-lang/rfcs#380

  • acrichto: At a high level, this doesn't change a lot. It's basically stating that the formatting syntax is stable in today's form.
  • acrichto: A few tweaks, removing a few of the formatting traits (Chat, Bool, etc), because they no longer make sense; you can just use the default formatter.
  • acrichto: The only traits left actually specify formatting
  • acrichto: Otherwise, the hidden features for the implementation is left unstable, so mostly unstable.
  • acrichto: There's still a weird fmt::Writer notion, which is left unstable (since associated items may change this).
  • acrichto: TL;DR: mostly stable syntax, mostly unstable implementation
  • brson: There's some dissent on the PR, e.g. from nrc
  • acrichto: At first, I suggested disallowing expr = expr in the language itself for future proofing. But instead, we're just going to standardize on the syntax in this macro, regardless of what we do with named args in the future.
  • brson: What about nrc's objections?
  • acrichto: Not sure. The scope of the RFC is pretty limited. I think his worries go way beyond this scope.
  • aturon: Since we're only stabilizing the syntax here, seems like nrc's objections are out of scope for this RFC.
  • pnkfelix: My main complaints about the formatting system aren't really addressed here. I'd like to eventually see support for adding quotes around strings for example. But that seems orthogonal.

Defaulted type params

rust-lang/rfcs#213

  • aturon: [explanation - nobody taking notes]
  • aturon: some other minor points, like specifying _ for accepting default
  • brson: why does this RFC allow any type param to have default values, instead of coming at end of type param list?
  • aturon: I read it differently.
  • brson: rule 1 says 'type params in any position can specify a default'
  • aturon: not sure
  • acrichto: today it's unclear where they can go, and this is clarifying that any type param list allows them, left hand are concrete, right hand can be defaulted
  • aturon: currently allowed on method typarams but doesn't do anything. this gives meaning to these cases
  • pnkfelix: clearer in detailed design, explicit that once a list declares a type param all others must have them

https://github.com/nikomatsakis/rfcs/blob/defaulted-type-params/active/0000-defaulted-type-params.md#type-parameters-with-defaults

  • aturon: only a few comments, lots went off track discussing interaction with hypothetical hkt. others fairly positive
  • aturon: i feel good about it. we're commited to ungating default params, and this cleans up the spec

RFC authors

rust-lang/rfcs#449

  • pnkfelix: I proposed we add a new field to the header info for an RFC, with the author name. I feel like the authors are getting lost when merging RFCs. You can track it down via commit history, but just doing a blame doesn't give you the right answer.
  • acrichto: I would expect you'd visit the PR via the RFC number
  • aturon: Name and email?
  • pnkfelix: Yes.
  • brson: Don't want to put too much weight on credit -- don't want to gamify RFCs. But could be useful to have contact info.
  • acrichto: I'm curious -- when I use blame, I get the right author. I'd be tempted to say that we always merge, never rebase.
  • brson: FWIW, PEPs have authors
  • pnkfelix: I'm swayed that we should avoid gamification.

"coerce" versus "view"

  • steveklabnik: Unsure whether to refer to references into an array as coercions or views, etc.
  • brson:
  • aturon: some text it guide led to this, takinga slice from a vec described as 'coercion' which was confusing, pr changed the term to 'view'. comes up a lot should decide on terminology
  • aturon: iow, we have terms like 'to', 'as', 'into' in method names ... should possibly

http://doc.rust-lang.org/guide-strings.html

Like vector slices, string slices are simply a pointer plus a length. This means that they're a 'view' into an already-allocated string, such as a &'static str or a String.

  • pnkfelix: 'coerce into' vs 'coerce to'. if i heard 'coerce' on its own i'd assume by value, but with 'coerce into' it really sounds like by-value
  • aturon: not a lot of strong opinion? i suggest that steve and i work together and think about this term
  • brson: to clarify we are happy with the term 'slice' for type names of views?
  • aturon: yes. this issue though not specific to slices. e.g. if you have &str and call as_bytes you get a byte slice. what did you do?
  • pnkfelix: that's not quite the same since the input there is a slice, which is Copy. doesn't matter to be taking it by value if it is freely copyable
  • aturon: main point is we need consistent terminology

Precedent of + in type grammar

rust-lang/rfcs#438

 &Object+Send       // before
 &(Object+Send)    // after
  • brson: another niko issue, aturon will represent
  • aturon: above snippet is the tldr. major change is how type grammar interacts with +. first example looks like & applies to Object
  • acrichto: confused about before/after table in RFC summary.
  • aturon: 'after' is what you have to write to get the before types
  • zwarich: & case seems like good motivator. second last example is always a type error, but in it the left hand size looks more intuitive to me
   Fn() -> Object+Send                Fn() -> (Object+Send)         // (*)
  • aturon: in detailed design this behavior around errors is treated as a seperate change, but not really motivated. i kind of agree with zwarich
  • pnkfelix: it says 'must give a type error' because the result must be Sized... oh, both are type errors, scratch that
  • brson: it sounds like we're not totally convinced by niko's arguments here?
  • aturon: feel like changing precedent for + and unary type operators makes sense. arrow does not seem well motivated
  • pnkfelix: he hasn't written an example like this, but presumably it could potentially be useful

(Fn() -> Object ) + Send

  • pnkfelix: i.e. this is how it would parse after the rfc w/o the parens
  • aturon: seems strange. doesn't match my gut instinct, also doesn't seem as useful
  • pnkfelix: i'd argue to require parens
  • brson: let's get clarifications from niko

jemalloc

rust-lang/rust#18678

  • pcwalton: There was a PR recently that removed the JE_ prefix. This touches on a lot of things.

(brson: motivation is to unify the C and Rust allocators by taking advantage of the weak symbols for malloc on unix; but there's a major problem that dlopening malloc is a major no-no because it causes different modules to use different implementations)

  • pcwalton: One thing it touches is: what allocator should we use for executables? Should we allow the system allocator to be subtituted for executables? What about C programs that embed Rust (loading it as a dynamic library). (And by Rust program, I mean one that uses libstd). And what should the defaults be?
  • pcwalton: The embedding case corresponds to things like Skylight, where you're embedding in a Ruby context for example.
  • pcwalton: Another question is whether you can even dlopen Rust programs from C programs.
  • pcwalton: There have been a number of conflicting statements in the thread.
  • pcwalton: We reached out to the jemalloc author to get clarity.
  • pcwalton: Currently, it is possible for C programs to dlopen Rust programs that use std (Skylight does this). But if we accept this PR, it would no longer be possible. Under this PR, any time you load a Rust library, it switches your allocator to jemalloc -- but you can't do that when the program is running!
  • pcwalton: The PR author suggested that dlopen doesn't currently work, but we have production users doing this. jemalloc's author confirmed
  • brson: To clarify, the jemalloc author agreed that there are problems dlopening jemalloc, though he couldn't recall specifics, and it is currently working for us.
  • pcwalton: Right, but we don't want to lock ourselves out completely.
  • pcwalton: Another problem is that, because we're using jemalloc-specific APIs (such as sized realloc), you can't switch to system malloc at runtime. We asked the jemalloc author whether these APIs are important, and he said they are only for niche use cases.
  • pcwalton: jemalloc's author suggested that we remove all jemalloc prioritary APIs, and link against malloc/free symbols via weak linkage. But we should link jemalloc by default for executables.
  • pcwalton: Basically, this woul dfollow the typical model in C programs, which link symbols malloc, realloc and free. When we are in control (making the executable) we use jemalloc by default (since we're tuned to it, and it's high performance). But in the library case, we'll use the default allocator, allowing the embedder to make their own decision.
  • pcwalton: This seems like the least surprising semantics. It also has the benefit that all C allocations (unless the C libraries are using custom allocs) will use the same allocator as Rust. That means that for rustc in particular, we'll be able to use jemalloc for LLVM, which will help. It avoids having multiple allocators, which is almost always a bad thing.
  • zwarich: There's another intermediate approach. We could use sized dealloc internally, but by default compile them into calls to free (erasing the size). So if you wanted to rebuild everything in Rust with sized dealloc yourself, you could. But otherwise, you get the benefit of the standard allocator like any C program.
  • pcwalton: That's right. We could stub the jemalloc API using weak symbols that by default call into the system allocator. But if/when jemalloc is linked, the real sized dealloc would override those symbols. That works fine for sized dealloc.
  • pcwalton: The PR author said that it wouldn't be possible for realloc, however, because of the way jemalloc's API works. I don't fully recall the details.
  • brson: jemalloc's author also expressed some skepticism about this strategy, so there may be some limitations there.
  • zwarich: sounds good to me. We've been sticking to the philosophy of Rust not having a runtime, and the increased incorporation of jemalloc-specific APIs goes against this.
  • acrichto: jemalloc is hidden behind an internal API currently, so in principle we could switch it out (though this is not being tested). I agree that we want to cut down the number of shims, but we also don't want to forbid access to what the system could provide.
  • acrichto: We've put a lot of design into allocators themselves (tracking sizes); we might want t rethink that design.
  • acrichto: Also, if it can be faster, may be good to expose it somehow. But not at the cost of integrating well in the C style
  • pcwalton: We could convert our API to be weak symbols -- use some approach like that. On the other hand, integration with a custom allocator seems somewhat unimportant; I think the most important thing is to get LLVM using jemalloc, and the best way to do that is to use jemalloc in the standard way. We definitely shouldn't sacrifice our ability to dlopen in the process.
  • brson: Sounds like there's overall agreement here to changing our approach; we can hash out the details separately. Any other concerns?
  • pnkfelix: I'd like to see the comments from the jemalloc author about the sized APIs not being so important; it may be a chicken-and-egg problem where existing C programs don't use it properly, but in Rust we have this information readily available.
  • brson: Right, and I don't want to close that door. I'll send you the email.
  • pcwalton: I believe that when the functionality was added to jemalloc, it was reducing a half dozen instructions at most (the fast path is roughly 85 instructions)
  • pnkfelix: May have more to do with cache misses
  • zwarich: Yes, for the metadata there's a potential miss. The other thing is that the internal jemalloc API is changing all the time, so we can't really stabilize on this for now.
  • pcwalton: Yes, the jemalloc author pointed this out as well
  • brson: He recommended against using any of these special APIs because of the maintenance issues
  • zwarich: Yeah, so not a great loss to not do this right now
  • acrichto: It might turn out that with custom allocators, someone can make certain vectors go way faster.
  • zwarich: If we want to have a test case for allocator design, jemalloc's features could serve well
  • brson: So, someone will have to hash out a new design and implement. But it's not a huge/1.0 priority.
  • pcwalton: Right, but I think we should close the PR, since it slams the door on dlopen, which we can't do.

Servo blockers

rust-lang/rust#18847

  • kmc: There's one issue I wanted to discuss: issue 18847 related to TCP streams.
  • kmc: Want to make sure there's progress on this; do you need anything from us?
  • acrichto: I poked at it last night. I don't use python, so if someone could give me exact repro steps, that would help a lot.