2015-02-17.md

Agenda 2015-02-17

• fott (acrichto)
• code completion (acrichto) rust-lang/rust#21323
• disclosure of security bugs (brson)
• release problems (brson)
• Servo, servo, servo (larsberg) servo/servo#2853
• meta-RFC reject/discourage "open-ended" proposals (pnkfelix) rust-lang/rfcs#851
• do future features (e.g. type-ascription) motivate changes to struct syntax now (pnkfelix) rust-lang/rfcs#841
• alpha2 schedule (nmatsakis)

Attending

steveklabnik, brson, acrichto, nmatsakis, larsberg, huonw, aturon, pcwalton

Status

• brson: packaging bugs, twir, release notes

Action Items

• brson: Open RFC issue about security policy
• niko: Land RFC on debug_assert

Friend of the Tree

Today I would like to nominate Toby Scrace as Friend of the Tree. Toby emailed me over the weekend about a login vulnerability on crates.io where you could log in to whomever the previously logged in user was regardless of whether the GitHub authentication was successful or not. I very much appreciate Toby emailing me privately ahead of time, and I definitely feel that Toby has earned becoming Friend of the Tree.

Security bugs

• larsberg: On Servo, we've been told we'll need a private issue tracker of some form - probably the bugzilla one so that we can keep the Mozilla security folks integrated in the process. Could also use a private github organization repo just for those issues.
• steveklabnik - rails has an email security@rubyonrails.org that goes to a subset of the core team, fixed as quickly as possible. http://rubyonrails.org/security/ <-
• acrichto: sucks to have to go to bugzilla and create an account
• pcwalton: it's the standand and we should follow
• brson: hopefully we don't have to use bugzilla in the rust project
• larsberg: should think it through, because you don't want to have to worry about the process when you're dealing with a security problem
• nmatsakis: we've always said we'll have to have a security policy, should bring in other people. maybe it's time
• aturon: good to have for 1.0 final

Code completion

rust-lang/rust#21323

• acrichto: You can give it a partially-written Rust program and then you can ask for completion at a given source location. Adds some stuff to the AST, etc. Seems a bit ad-hoc. Not sure what others think about this. Maybe support from the rustc APIs instead?
• brson: Don't feel strongly, but if we start down this road, I'd like to have the author taking it to a full feature.
• huonw: I don't think concerns about binary vs. library matter so much: we have to start somewhere.
• brson: Pretty small patch in its current form. And pretty invisible.
• nmatsakis: This approach is not going to work, right?
• acrichto: If you want to do code completion, isn't there more you need to do?
• pcwalton: This is the reason rustfmt does not use an AST - modeled on clangfmt, which does not use an AST. Not surprised if code completion is not based on AST. Expect there's an index prebuilt.
• larsberg: Yes. Typically completion occurs based on data produced by the compiler + some in-IDE knowledge from a more incomplete-friendly parser in the editor. The compiler usually only handles tools like suggested fixups for parse errors.
• aturon: So, probably we should start with an RFC that sets out a path forward for devtools?
• nmatsakis: Not a fan of making changes to the AST unless they're part of an overall plan forward.

Open-ended proposals.

rust-lang/rfcs#851

• pnkfelix: There was an RFC that did not propose a solution / design directly. This led to less than useful comments about a bunch of different possible designs (none of which were actually suggested for implementation).
• nmatsakis: I agree. Suggesting an RFC means at least picking a favorite. Makes sense to spell out alternatives, and might have some stuff unresolved...
• steve: An RFC should have a detailed design. Otherwise, you can make an issue in the repo.
• pnkfelix: Is it OK to change the wording for suggested RFCs? i.e., that we would close such PRs?
• brson: There's some judgement involved here, so don't need deep explanation.
• nmatsakis: It is nice to have a list of reasons that you will close things summarily.
• pnkfelix: I'll look over the process docs to see if they need a change.

Struct syntax

rust-lang/rfcs#841

• pnkfelix: nrc put up a thread about type ascriptions and colons. People seemed unhappy about some of the conflicts between allowing them everywhere and combine that with struct literal / pattern syntax. So, are you writing down an identifier with a type or a field name and the pattern to use? Some people suggested changing the struct literal syntax altogether. That was the RFC <d/c>
• nmatsakis: No.
• pcwalton: We have discussed the struct literal syntax many times over several years. I'm not interested in going with something non-standard. Also not a fan of the gcc dot-prefix thing, since it's just a GCC C99 lang extension thing.

  Foo { .foo = <expr> }

• nmatsakis: We're just past the point where we can make very large breaking syntax changes without having excellent motivating reasons to do so.
• pcwalton: There was also no consensus on what to change to. It's not clear there's anything that we could change it to. What we have today has precedence and familiarity. Even JS has gone with : for type ascriptions, despite much worse overlap!
• pnkfelix: As long as we restrict it to expressions, we shouldn't have a problem. Just when embedded in patterns, but I'm not convinced that's useful anyway.
• nmatsakis: Not that it's impossible, just that it would require some dark corners.
• pcwalton: Maybe useful if you have a let mut x = None and then pattern match on x, where you might want to annotate the type...
• nmatsakis: I think we're done with this topic.

Servo, servo servo

• larsberg: huge compile time perf increase by turning off LLVM asserts. trying to make android builds deterministic, previously lots of hacks running sed over cargo output. waiting on acrichto to solve.
• acrichto: the 'cargo rustc' command might work for you. (?)
• larsberg: solves the biggest one - that we need to control linking. other issue is that sometimes we want to like call 'time-passes' but you can't get cargo to do that. sometimes you just want to pass a flag to rustc.

alpha2 release

• nmatsakis: Any schedule for the issuing of the binary? I think last time acrichto spent three sleepless days doing rollups... homu is definitely helping, but it's slow progress right now.
• acrichto: Tonight and tomorrow night I can do rollups.
• nmatsakis: Deadline? Tomorrow night?
• acrichto: That's what we used last time.
• nmatsakis: That sound good?
• brson: I have a few issues. The installer and buildbots have interacted badly, so no nightlies for several days. This must be solved...
• nmatsakis: Been trying to get a snapshot for several days...
• aturon: We have a couple of PRs in the libraries to land, but nothing urgent. Prioritze language over library changes.
• acrichto: Variance branch; unsafe destructor; overflow changes.
• nmatsakis: Been trying to reach aatch to find out the overflow status. huonw, can you try to reach him? I don't have good time zone overlap with him.
• huonw: Sure!
• nmatsakis: Doesn't have to be perfect, but hopefully we can land something.
• pnkfelix: No more for unsafe destructor into alpha2. Still requiring the attribute because we don't trust the check and there are some other checks we don't have yet. e.g., if you can add bounds on a trait without putting them on the initial structure. Anyway, nothing blocking alpha2 there.
• aturon: If people have some time to push on the integer audit (there's an issue to claim modules), we could probably do it.
• nmatsakis: We're about halfway there.

Integer suffixes

• nmatsakis: Another thing is the RFC on integer suffixes. A consensus has emerged around the full name of the type. Patch is almost ready. Can we approve the RFC?
• brson: I really hate using those long names... I was so happy about short ones, and now, bam, isize!
• nmatsakis: Very rarely used; I mainly have just been removing suffixes. Seemed like the only consistent rule, but I know...
• brson: I even liked isz and usz; they have a cool pronunciation...
• nmatsakis: Better make your case quickly!
• brson: Nah.
• steve: Seem rare.
• pcwalton: I don't care at all, though I am partial to eddyb's suggestion to remove all suffixes once we have ascription.
• nmatsakis: You can almost write as type today and it works fine.
• pcwalton: I usually prefer longer names.

Overflow

• pcwalton: Didn't realize -O does not turn on NDEBUG. Moreover, the config switch to build libraries witout debugging assertions on is pretty well hidden and we don't distribute anything with it. Feels like there's a use case for building with -O and asserts on, but seems to be rarer than with -O and asserts off. IF you're optimizing, you're already dropping debuggability for perf and most people want to go the whole way. Requiring CFG_DISABLE_DEBUG=1 make is hard. Worse, overflow only enabled with --cfg NDEBUG. So it's gonna be a huge gotcha for benchmarks, etc. I feel that -O should imply --cfg NDEBUG by default.
• nmatsakis: RFC 563. I totally agree. It says to move off of NDEBUG and instead of debug assertions.
• pcwalton: Noticed this when microoptimizing refcell stuff...
• brson: Somebody land it?
• nmatsakis: I guess that's me!
• larsberg: We will want to be able to control this from the top level in Servo...
• pcwalton: Yes!
• acrichto: We have profiles that will let you tweak those.