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

Latest commit

 

History

History
226 lines (188 loc) · 14.8 KB

2014-09-30.md

File metadata and controls

226 lines (188 loc) · 14.8 KB
Raw

Agenda 2014-09-30

Attending

brson, nrc, zwarich, nmatsakis, aturon, acrichto, steveklabnik, pcwalton, pnkfelix, larsberg

Status

  • acrichto: cargo registry design & impl, cargo tweaks for servo, rust rollups
  • brson: pm, final windows fixes, hellgating, combined install, release automation
  • aturon: Runtime removal, num simplification, conventions RFCs, error handling
  • pnkfelix: Box syntax, landing nonzero-drop support
  • pcwalton: P-backcompat-lang

Action Items

GC

rust-lang/rfcs#256

  • brson: We have an RFC to remove Gc. I think it's pretty straightforward.
  • pnkfelix: No comments to make -- seems like no negative responses
  • zwarich: The only concern in the comments is, will the lang item be removed?
  • pnkfelix: Yes.
  • brson: Should we do this? [ all : yes ]

Static const

rust-lang/rfcs#246

  • brson: RFC to change how static works.
  • acrichto: It's been open for a while and there's been some discussion. Mostly positive.
  • brson: We never fully decided whether we want to commit to this for 1.0
  • acrichto: If we accept, makes a lot of sense to do for 1.0, everything that's a static today should be a const
  • brson: [missed]
  • nmatsakis: If we accept the RFC, we can always "unaccept" if we can't get to it
  • nmatsakis: How much work?
  • acrichto: I think not much -- the basic functionality is there, but needs to be rewired
  • nmatsakis: Scheduling is my biggest concern. It does seem nicer.
  • brson: I'm inclined to do this. Seems like there may be some schedule availability. [ all: let's merge ]

Object safety rules

rust-lang/rfcs#255

  • nrc: Today, there are certain methods that you can't call on a trait object. For example, things that use generics, or Self args/returns, or by-value self. We just forbid calling those on trait object.
  • nrc: This RFC takes a different approach. It forbids you from making a trait object at all, if there are any such methods. So you move the error from the call site to object creation.
  • nrc: The motivation is, for DST we'd like to automatically consider a trait object to implement itself.
  • nrc: The only way we can sensibly do that is by enforcing this check on the validity for trait objects. Otherwise you could circumvent the check.
  • nrc: The downside is that things are less flexible -- there are things today that won't work. But you get better error messages and easily predicatable behavior for the DST bit.
  • nmatsakis: You can always refactor your traits to work around this.
  • pnkfelix: Any data about how often that's used in the current codebase?
  • pnkfelix: I'm in favor.
  • zwarich: There's a workaround for not having UFCS, that's in use in Servo. I'm trying to get rid of it. But you can cast something to a trait object and call a method on it to disambiguate methods on the same name for different traits
  • nmatsakis: UFCS can be imlemented today with function wrappers, so I don't understand the motivation
  • nrc: Except if you're doing something unsized, the unification bug will prevent you from doing this.
  • aturon: If we do this now, we can always become more permissive later on. So this RFC is a conservative approach.
  • aturon: To clarify, though, the main motivation is for programmer understanding, or for soundness issues?
  • nrc: Mainly for programmer understanding. You could only provide the impls when safe, but that would be confusing and it'd be hard to give good error messages.
  • aturon: I think I'm in favor.
  • nmatsakis: Also, this encourages you to factor into object-safe traits, which brings greater awareness to the tradeoffs.
  • pcwalton: Concerned about scope creep. This and the static const RFCs are fine, but as want-to-haves. If we can't get them done by the end of the year, I don't want to hold up the release on this basis.
  • nmatsakis: We don't use that many objects. Should be OK.
  • nmatsakis: I will merge.

Cycle time

  • pcwalton: We had a large performance regression, where match and borrow checking took much longer than type-checking. I've fixed it, but before I did it got snapshotted.

  • pcwalton: I'm concerned about a few things. We have no infrastructure to catch these regressions. And apparently, the compile times for rustc are so bad that people didn't even notice a 2x slowdown -- everyone assumes it's just slow.

  • pcwalton: The code I fixed was two years old, so the issue has been lurking. But I think it was activated by eddyb's patch that introduced a lot of lifetimes.

  • acrichto: Fixed in master, though?

  • pcwalton: But not in stage0

  • acrichto: So, I haven't seen any major regressions on the last 10 builds

  • brson: Not seeing this in the bots

  • acrichto: I do share the concern about compile times.

  • pcwalton: Maybe people should compile with time passes

  • pcwalton: Also, can we turn on parallel builds by default?

  • nrc: Yes, there's a patch almost ready to go, not sure what happened.

  • pcwalton: Someone should push on that. I think that's a large productivity boost for the rest of the team.

  • nrc: I can do that.

  • brson: Please reach out to Stuart on incremental compilation, as well

  • nrc: The last I heard (just after he left) is that it was almost ready, and he was planning to finish it up soon

  • pcwalton: For Servo, it'd be a productivity multiplier for sure

  • brson: We can also go back to the idea of ratcheting

  • aturon: We could do something simple, like have bors track the average times and gate merging on being within "normal" variance

  • pnkfelix: Isn't there a graph of perf times that huon runs? I can't find the regression.

  • nmatsakis: I'm skeptical of automated ratcheting, because it tends to be unreliable.

  • acrichto: For perf regressions on the compiler, it's important, but not for 1.0

  • pcwalton: Oh, definitely. Just something to keep an eye on.

  • brson: This kind of thing has long been a "low priority" thing, keeps getting pushed back

  • pcwalton: I think after 1.0, some of us spending time on compiler perf will be important (as opposed to new lang features). To be honest, compiler performance matters way more in my day-to-day life than e.g. multidispatch

  • nrc: Also code quality, tool usability -- all these "soft" things around the compiler -- there's a lot to do after 1.0

    http://huonw.github.io/isrustfastyet/buildbot/

empty struct syntax

rust-lang/rfcs#218

  • pnkfelix: This reopens a previous suggestion to allow curly brace syntax for empty structs. The main motivation is to avoid special-casing in macros (and other code generators).
  • pnkfelix: Many said they want to just always require the braces, and dropping the sugar that allows them to be omitted. Hard to tell if that's a vocal minority or a widespread attitude.
  • pnkfelix: Also, the RFC suggests being lenient about braces. But then, should I be allowed to use parens as well (for empty tuple structs). But then there's an ambiguity between the struct name itself versus the function to create a struct instance. But I didn't want to go there.
  • brson: So it leaves the macro situation kinda half-solved?
  • pnkfelix: My instinct has been that code gens will generate curly brace structs with fields; I have a hard time imagining a well-designed macro generating tuple structs. But maybe I'm missing an obvious use case here.
  • nmatsakis: In the case of tuple structs, you can introduce extra parens to work around this -- not very nice.
  • pnkfelix: The other approach is to always require braces; you can always use an enum with a single variant to get today's semicolon-declared structs
  • nmatsakis: You're assuming that a struct with braces but no fields is the same as a struct with a semicolon. But you could vary the namespacing. [ a bit of discussion missed ]
  • nrc: Why is the no field struct in the value namespace?
  • nmatsakis: If you write let x = Foo;, the Foo there is an expression. But with Foo { then it's a struct literal, and hence a type name.
  • nrc: Right. But why do you not treat the first as a degenerate issue of the second one?
  • nmatsakis: We always know which namespace to check. That way you can avoid ambiguity with static constants, etc.
  • nrc: Makes me favor always requiring braces, to remove this special casing
  • aturon: I'm skeptical about the motivation for macros. Is it really so bad?
  • pnkfelix: You can definitely work around it. But one problem is if you're using a cfg attribute around fields, you might or might not have an empty struct, and that's harder to deal with.
  • nmatsakis: Also, this is backwards compatible.
  • pnkfelix: Unless we always required braces.
  • nrc: I do really hate it when I add a field and then have to go add braces. The inconsistency bothers me. Also, inconsistency between empty traits and empty structs. But it's backcompat. Though we should also consider ergonomics.
  • brson: Let's take this discussion offline for now.

Macro syntax

rust-lang/rfcs#208

  • nmatsakis: still want some changes to RFC: if there's a macro in scope can't be used as an attribute.
  • nmatsakis: think the exact text about disambiguation is still minor.
  • aturon: though these changes are minor, the community has some strong feelings about this topic. perhaps we open a new RFC
  • pcwalton: I'd prefer niko do it
  • nmatsakis: I'll adapt it
  • pnkfelix: wanted to mention that when I remade the struct RFC's i attempted to summarize the other views. when we create new RFC's it's probably a good idea to summarize past discussions.
  • nmatsakis: agree

Rustdoc math

rust-lang/rust#17390

  • acrichto: Hoedown recently picked up latex-style math support, powered initially by mathjax. Since then, they moved to something called [missed]. There's a Common Markdown proposal which does not include this extension. So if we add support for math, we might not be able to migrate to Common Markdown in the future.
  • acrichto: It's opt-in.
  • nmatsakis: This intersects the discussion about moving away from markdown
  • nmatsakis: On the one hand, I don't want to adopt every random markdown extension, but I also don't want to be stuck with the least-common denominator.
  • brson: But this brings in new deps? In tree?
  • acrichto: Only js deps. All distributed with rustdoc. No dependency on node.js
  • brson: Does this work with pdf mode/latex?
  • brson: Oh, we use pandoc for that. Is this extension compatible?
  • acrichto: Unsure
  • acrichto: I'm pretty lukewarm on this
  • steveklabnik: It would help with the reference
  • brson: I'm also lukewarm on this, doesn't seem like a lot of demand
  • acrichto: I know huon wants it (his PR) and Gankro for documenting collections

while let

rust-lang/rfcs#214

  • aturon: followup to if let, accepted a month ago. this proposal is simpler, desugaring to loop with match + break
  • aturon: motivation: 1) borrowing if let from swift, so consistency, 2) some specific examples that look cleaner. in general iterators can be introduced to use for syntax, but this can be simpler. basic response is enthusiastic. proposed to go behind feature gate so we have an out still
  • acrichto: same feature gate or different?
  • aturon: different
  • brson: if let is more obviously useful, so diferent makes sense to me
  • zwarich: if you are iterating over a worklist that's being modified in the loop it's useful.
  • aturon: I don't worry about schedule here. I think it makes sense to accept since we have the other
  • nrc: agree

Release builds by default

rust-lang/rust#17496

  • brson: There's a PR that turns off the debug build flag by default, with the goal of speeding up the compiler. I'm skeptical, because in the past when we've done this we've lost a lot of debugging.
  • acrichto: In particular, debug asserts in std go away
  • pcwalton: I think we have to do this if we want to be production-ready. It's a matter of when, not if.
  • nmatsakis: Can we do something different for snapshots and nightlies? Bugs in snapshots are a real problem
  • brson: I think the same argument will apply to release builds as well
  • pnkfelix: We can have mirrored versions with debug info
  • brson: Same for snapshots
  • zwarich: LLVM does asserts on by default if you're building yourself, but turns them off for releases
  • brson: This PR proposes to turn off debug info across the board. What you're proposing would be reasonable
  • acrichto: Recently ran into problems with Cargo where debug info would've helped
  • nmatsakis: Having debug builds around would help
  • acrichto: More infrastructure
  • brson: Produce two nightlies?
  • pnkfelix: Seems excessive
  • nrc: We make the hash for the nightlies available, you could always build it yourself
  • acrichto: But that's pretty slow.
  • nrc: We don't have "make release"/"make develop" right now, right?
  • brson: There's a configure flag, --debug, that's being flipped here
  • nrc: Especially with the parallel and incremental build stuff landing, the proposal was to add metaflags like make release/develop that would toggle these features. I think strcat has a good point that release should be the default
  • nrc: I want to avoid people having to memorize a ton of flags to get the best build
  • brson: We also have --release-channel for the release automation. I also don't want casual users to change the release channel.
  • acrichto: I also think if you're hacking on rust you want debug info
  • aturon: Just to be clear, cargo gives you profiles. But nrc, sounds like you want this for building rust specifically?
  • nrc: Yes.

[...]

  • acrichto: The set of people working on rust is way bigger than the set distributing it
  • nrc: But the people using the distribution is the biggest set of all

[... some missed ...]

  • acrichto: It sounds like we should configure the bots, but not change the defaults for people doing their own builds
  • pnkfelix: The snapshots would still have debug enabled?
  • acrichto: Yes, we'd change only the nightlies.
  • brson: How to move forward? Should we open an issue?
  • nrc: It ties in closely with parallel build by default, so I'll tie them together in an issue
  • pnkfelix: Did you say there was a discuss thread?
  • nrc: Yes, on parallel builds by default