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

Latest commit

 

History

History
115 lines (96 loc) · 11.5 KB

2014-10-21.md

File metadata and controls

115 lines (96 loc) · 11.5 KB

Agenda 2014-10-21

Attending

  • larsberg, wycats, pnkfelix, zwarich, acrichto, pcwalton, nrc

Not attending b/c conferences

  • brson, nmatsakis, aturon

Actions

Servo hi-pri blockers

  • lars: Pretty good shape but Patrick found a few things. Acrichto has been fixing some cargo issues and we don't have any other things we're waiting on for the compiler.
  • lars: Patrick will open an issue?
  • pcwalton: Yeah Rust and Cargo have a bit of a different opinion of whether you downstream dependencies should be linked statically or dynamically. This normally doesn't cause any problems but for libs that are shipped via dylibs it can be a problem. You normally don't want everything linked dynamically but rather everything linked statically into one dylib. There should be some way to turn it off and stop doing what it currently does. We'll have a hack to convert a staticlib into a dylib as a final step, but it's really gross. There should be a way for Rust to produce a dylib but link all upstream deps statically. Any method is fine as long as there's a way to do it.
  • wycats: Skylight has exactly the same situation, and the solution is the same. I think we want a way to say the final artifact should be a dylib and the intermediate parts shouldn't be dynamic. I think it's a bug that it doesn't currently happen like that.
  • pcwalton: It's fine with me if we always link downstream dependencies as static libraries.
  • wycats: Seems like we should try that.
  • acrichto: Hearkens back to when all we had were dylibs, but it's a different world today. Now, having dylib not be an intermediate format and only rlibs as intermediates makes sense. This does require an RFC, even though it would probably be unanimously accepted. It would help with distribution costs. Wait, no, because of the way the compiler dynamically loads a Rust library requires it to dynamically load all of the associated Rust standard libraries. I suspect we can't have only rlibs as an intermediate form.
  • wycats: When building a Cargo artifact, maybe rlibs would be the default? We'd probably want to have intermediate dylibs for people putting things on package managers anyway.
  • pcwalton: Flag to rustc?
  • wycats: Always upstream static. Once people ask for it, add the flag...
  • pcwalton: acrichto said we always have to have that flag in order for compiler plugins to work.
  • wycats: The flag would allow dynamic upstream libraries, but do we need it to change how things look?
  • acrichto: Need the flag because it would change whether you statically or dynamically link to the standard libraries.
  • pcwalton: Two commandline flags. One for rustc. But we may not need that option for Cargo. e.g. --prefer-dynamic-upstream to rustc. That flag might not be required for Cargo.
  • acrichto: Already have -C prefer-dynamic. We could alter the meaning of it from default-rlib.
  • pcwalton: Would you be willing to write the RFC, acrichto?
  • acrichto: Yes.
  • acrichto: lars, are cef/tedios upgrades very pressing?
  • lars: Not entirely, we've had problems with Cargo.lock merges in upgrades, but it would just be a nice fix but not blocking.

Failing in dtors

  • nrc: Might have to wait for more people - needs a language change.

Module reform #385

  • nrc: aturon asked me to bring this up. nmatsakis and he are in favor of it. This is kimundi's RFC. Proposes several things, especially removing ordering restrictions between use and extern crate and everything else. Since RFC 50 was accepted, there's no need for the restriction. Option to keep it as a lint, but not wide support for that. There's also adding pub extern crate that works like pub use, which does an extern and makes the toplevel module available. Finally, allowing extern crate in blocks other than modules in the same way that modules can be used. All seem like tidy-ups and are backwards-compatible, too. Could either postpone this, or accept it and try out parts. For example, relaxing the ordering is a wart that annoys a lot of people and we'd accept a pre-1.0 patch if somebody did it. So there's a good reason to accept it now.
  • acrichto: This does seem unambiguously good.
  • nrc: Only downside is around hygiene with extern crate in blocks. How does that work if it's in a macro? That's the downside. Personally, extern crates seem like a different class of statements; I'd say don't even allow them in modules, though this kinda breaks test modules and macros, etc. If you're going to accept them there, it makes sense to have them in functions and blocks, and maybe we have to put off thinking about it until we get in touch with jclements.
  • zwarich: Something weird about pub extern crate because it exports a module, not a crate. I know Rust does not fully distinguish between modules and crates (crates are modules with extra attributes), but this seems weird. Also strange because a crates is a translation unit - what does it mean to export it?
  • acrichto: This is taking crates from the module aspect, thoug...
  • zwarich: That makes sense. I think the lint is definitely a bad idea. "this ordering is confusing, so let's make a lint on by default to enforce that confusing ordering!"
  • nrc: That was the agreement on the lint from the discussion as well.
  • wycats: Intuitively, it feels like pub use, which isn't crazy (related to translation units).
  • acrichto: nmatsakis and aturon in favor? Then does anybody object to this? Who's the shepard?
  • nrc: aturon
  • acrichto: nrc, do you want to merge it?
  • nrc: Should we ask for them to remove the lint stuff first?
  • acrichto: Yes.
  • nrc: I'll make a comment to that effect and then we can merge it.

Fixed sized arrays and moving

  • zwarich:To pnkfelix's question. On borrowchk 1.0 questions, I think we said that it shouldn't be index-sensitive because it's a lot of work for little benefit. So I'm in favor of that change. I'd normally say to have a PR for it, but it's generated a lot of community interested (around drop semantics), so it might be worth having a really small RFC to make sure people can understand the change.
  • pnkfelix: Anybody want an overview first? Issue is that currently in Rust if you hav ea fixed-sized array and then immediately move the whole array, you can't read from it anymore, but you can still write into it! We honor the fact that we will tear down the objects that you wrote into it properly. There's a link to a playpen that shows it in action. You can write stuff into an array, but since it's been moved you can't read the stuff you've put in there! And it'll still get dropped correctly.
  • acrichto: So it's a sink?
  • pcwalton: This is just a bug. It's so totally insane that it is not a feature. I would even fix this post-1.0 if we saw it then. The ability to create bitbuckets in this way is not a feature of the language.
  • pnkfelix: My thought process was just to file a bug and fix the borrowchecker. Should we RFC it?
  • pcwalton: That's not worth an RFC.
  • acrichto: How does this relate to moving out of one element?
  • pnkfelix: Woudl still support moving out of one element.
  • zwarich: I was saying that what we don't do is if we have 100 elements, we don't track which ones we've moved out of (e.g., 4, 8, and 24 separately), we just track that after you've moved out of a first one, you've moved. Not clear whether in the future we should support tracking separate moves later, but certainly not for 1.0.
  • pnkfelix: OK. zwarich, are you OK with not having an RFC for that?
  • zwarich: If everybody else is OK with handling it as a bug and not an RFC, I'm OK. Just wanted to make sure since there was a lot of interest.
  • wycats: Yeah, considering this as anything other than a bug is pretty absurd.

pub markers & public trait items #227

  • pnkfelix: Would like some feedback to make sure I shouldn't shut this down right now. Not looking for approval, but some info would be great. RFC PR 227. Inspired by a previous RFC to allow private trait items. We closed saying it would be nice to do later. In response, the author said that maybe we should do some future-proofing by requiring pub markers on every item in traits.
  • wycats: Was hard to get used to not using pub, since the syntax is similar to everything else, but doesn't have the attribute.
  • acrichto: We have a postponed RFC, but if we have this distinction, are we committing to the postponed work?
  • wycats: If we don't put in pub now, we can't accept the RFC ever.
  • acrichto: Could do something else that lets us add it...
  • wycats: You can imagine something inconsistent that would work, but I agree with the RFC author that if we're not sure we should require pub now.
  • pnkfelix: Would also be nice for cut/past when you move them from impl to a trait definition.
  • wycats: I just found it confusing that it's the only place where you don't need pub.
  • pnkfelix: Don't need a decision now, but just wanted some early feedback. Who has strong objections? acrichto?
  • acrichto: I'm lukewarm to just adding more and more stuff.
  • nrc: My intuition is that they should be pub by default on traits, but I'm sympathetic to the consistency argument.
  • wycats: Also not crazy to want private trait methods. Might have some internal traits.
  • acrichto: Can I still implement the trait outside the module?
  • pnkfelix: Yes if there are default methods.
  • acrichto: So private trait methods can only be default?
  • wycats: Need a default or can't be implemented outside the module. But that's OK.
  • acrichto: My hesitation is that I don't understand what it means to have a private trait item. Maybe nice because it lets you prevent someone else from implementing it. Kinda weird that you have this public thing with private implementation details, but it's exposed...
  • wycats: Maybe you want to expose it but don't want to let people implement it.
  • zwarich: Whether or not somebody is allowed to implement your trait may therefore be a function of the trait item in the module. So you could make trait items that are only callable from other trait items, which is another interpretation. If you desugar traits into modules, that's what the privacy would correspond to, rather than about exposing the trait method to the enclosing module. Not entirely clear what the interpretation is.
  • wycats: I agree. If we don't future-proof the language, the resulting syntax will be unpleasant.
  • pnkfelix: I'll bring it up again in front of the full quorum.