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

Latest commit

 

History

History
109 lines (92 loc) · 9.19 KB

2015-03-17.md

File metadata and controls

109 lines (92 loc) · 9.19 KB

Agenda 2015-03-17

attending

brson, acrichto, pcwalton, aturon, larsberg, nrc, steveklabnik, pnkfelix, huon

status

  • brson: making undeclared features errors, ci reporting
  • acrichto: I/O stabilization, pushing cargo towards stable
  • nrc: coercions, pub use bugs
  • aturon: stabilization (num, conversions), blogging, new lib work

action items

Servo update

  • lars: Servo is in the middle of a rustup. We're hitting a compiler ICE, a borrowck regression which causes code to have to pull things out into a bunch of let bindings, and problems with DST coercions.
  • lars: From the Servo side, it seemed like some of the DST work was approved but not clearly on the 1.0 roadmap. We have a ton of unsafe code working around it, but we would really like to use DST instead.
  • pcwalton: Arc in particular. Right now, we have to pretend that it's a Box (which involves allocating a box when we free it). eddyb has landed an additional workaround.
  • pcwalton: The fact that we're doing these crazy hacks is kind of ridiculous.
  • nrc: We're on it. I just talked to nmatsakis about it. The only missing bit is custom DST coercions. That has been deprioritized because no one was asking for it, but we've bumped it up
  • nrc: It's not on the 1.0 milestone because there's no backcompat risk, but it's very high priority.
  • nrc: I've posted an RFC, not many comments yet.
  • lars: That's great, thanks nrc!
  • brson: Workaround for ICEs?
  • lars: Not blocking us yet. We have two rustups in parallel. The most recent one will break html5ever
  • acrichto: This ICE is very suspicious. It's from an arith overflow, and if you're optimizing the compiler those should all be going away. It's a bug, but it shouldn't be showing up.
  • nmatsakis: Is that tied to optimization or to the debug assert flag?
  • acrichto: It's both. You can enable force overflow checks or debug asserts. But if you pass -O it turns this all off. It landed a few days ago. There was a short window before that happened, but the change itself landed a little while back.
  • lars: so in theory this should be gone. But maybe we need to recheck our deps with the latest rustup. Sometimes we pick up random nightlies.
  • pnkfelix: Is there a bug filed for this particular overflow?
  • acrichto: Yes. For now: just optimize the compiler.
  • pnkfelix: So, on the borrowck issue: I wasn't planning to do this for 1.0. How important is it?
  • lars: It's about 100loc for Servo. Not a huge deal, no unsafety, but it's really ugly. Seems backcompat to fix.
  • pnkfelix: The most obvious fix would have worse fallout, I suspect, so it may take some time.
  • lars: My worry is that borrowck will be harder to tweak after 1.0
  • pnkfelix: I think we can make things finer grained later on, so this shouldn't be too bad.

Checked overflow and casts

  • pnkfelix: Linked to an internals post trying to get some feedback. [missed]
  • pnkfelix: If you have a function like:
fn f_i32_to_u8(x: i32) -> u8 { x as u8 }
f_i32_to_u8(-100000)
f_i32_to_u8(-1)

fn f_i8_to_u8(x: i8) -> u8 { x as u8 }
f_i8_to_u8(-1)
  • pnkfelix: The question is, what do you do with calls like the above? Similarly, if you have function that takes and produces the same size but does a sign conversion. What should happen?
  • pnkfelix: The strict semantics I thought were intended says that if the input argument, interpreted as a signed integer, if it falls into the range of the target then it succeeds, otherwise, panics.
  • pnkfelix: So for all of these examples, passing in -1 should panic when overflow is turned on.
  • pnkfelix: What I tried to get across in the internals post is, if you consider the goal to be to catch bugs, this seems to obviously help catching bugs if you're throwing away bits.
  • pnkfelix: The people who commented all expected the strict interpretation. That means signed -> unsigned could panic, and vice versa. Just wanted to check that people are on board with that.
  • brson: What if you want a bitwise conversion?
  • pnkfelix: Presumably, we'd have something analogous to the methods for modular arithmetic, but for conversion. That doesn't solve the constexpr problem. We'd have to figure that out -- maybe eddyb's work could help here. But that's an example of something I'm not thrilled about. Personally, I was pushing more for something where a bit-for-bit conversion would never panic.
  • brson: I generally expect to be able to cast signed/unsigned at will.
  • nmatsakis: They all make a certain amount of sense. But first off, you'd call x.wrapped_as::<u8>() or something like that.
  • nmatsakis: I think the reason that people prefer the strict semantics is that you're thinking about integers in the mathematical sense, not the bitwise sense; if you want to think at the bit level, use the wrapped operations.
  • pnkfelix: I disagree: isn't as really about bits?
  • nmatsakis: I'm not sure. If you're using unsigned as a kind of assertion...
  • brson: This kind of a change would silently break a lot of code. You're not going to know unless you have good test coverage in debug mode.
  • pnkfelix: That's true in general with the overflow change.
  • acrichto: I feel that I use as in a bitcasting sense far more often. That is, a higher percentage of as want to be wrapping that uses of +, so I'm not sure about these defaults.
  • pcwalton: I use as for bitcasts pretty much exclusively. Part of the reason for that is that as is pretty bad for non-bitcasting things -- in particular, between floats and ints, because it rounds down. Yesterday, I was fixing a bunch of rounding error bugs in Servo that were using as to convert from float to int when they should have been using round. So it's already a poor tool if you're not doing bitcasting.
  • nrc: It seems the root problem is that we have a single data type that represent two kinds of data, and we're trying to make the operations "just work", which isn't going to happen. Seems like we need an explicit division between operations on numbers and operations on bits. Seems like as is a bit operation, but people are using it on numbers. But if you're saying "I mostly use + for numbers but as for bits", you're making a somewhat ad hoc choice.
  • aturon: Note, we do have a type distinction via Wrapping, and + is interpreted differently on that type. We could do the same for as, potentially. But it hasn't been very ergonomic, and an alternative is Swift's approach of separate operators.
  • pnkfelix: So the question is what to do in the short term.
  • nmatsakis: Maybe we need more comments on the thread... this meeting has changed my opinion.
  • brson: I feel nervous about the fallout of the changes to sign at this stage of the game
  • pnkfelix: Yes, but it's now or never.
  • nrc: I think we want one extreme or the other; I feel uncomfortable with the middle ground of Felix's proposal. Either it's a bit operation, or it isn't (for as itself).
  • aturon: Can we set a deadline to make a decision? (People agree: one week from now)

hyphens and crate names

  • acrichto: State of the world has changed! Proposal now says that we remove the quotes from the extern crate and cargo translates hyphens to underscores. So you can have hyphens and it will translate to underscores locally. Cargo will also block having two crates that differ only by hyphen vs. underscore. I feel pretty good about this.
  • aturon: I like this a lot. Seems like a win on all fronts: match Github conventions, write something reasonable in your toml file, and good ergonomics on the Rust front
  • nrc: And if you don't use cargo? You get underscores on-disk, etc?
  • aturon: Yes.
  • nmatsakis: This is exactly what I was hoping to propose!
  • brson: If we did this, what's the transition there?
  • acrichto: First, we have lots of deprecation messages on the quote syntax. Then, cargo might start passing some args...
  • brson: No crates registered that would violate this restriction?
  • acrichto: Correct.
  • brson: Seems good to me.
  • lars: We have workflow where we have packages in crates.io but then we have to locally customize them. Is any part of this specific to crates.io that would break if you were using github? Specifically, if you're doing a local override with a github version. Do we have to change a bunch of sources?
  • acrichto: I think it'll work just fine. In Cargo manifests, you'd use hyphens everywhere; in Rust source, underscores everywhere.
  • brson: We have a rule where if there's no crate name defineds [missed]
  • acrichto: We would probably generate an error. One of the goals is to remove special logic in rustc itself. We're just going to remove the hyphen handling. So if you call rustc directly you will have trouble.
  • brson: And the output will reference the underscore?
  • acrichto: Yes
  • brson: Sounds good.