Meeting 2015 01 12

Servo Meeting 2015-01-12

Agenda items

• Notes about CSS parser and style system changes (SimonSapin)
• Postmortem: Memory corruption during the last upgrade we just "avoided"? (larsberg)
• Reminder: going to start the alpha Rust upgrade soon - 00b112c45a604fa6f4b59af2a40c9deeadfdb7c6 snap exists (larsberg)

Attending

• larsberg, kmc, Manishearth, Ms2ger, pcwalton, brson, mrobinson, zwarich, mbrubeck, jack, SimonSapin, jdm

CSS parser & style

• SimonSapin: Currently, the CSS parser in Servo's tokenizer does some parsing as well finding blocks with braces, parens and function. It'll yield tokens and component values. These component values can have a vector of values. It has the nesting correct so that we can't get it wrong. Now, we have to add lots more parsing code every time we add a new CSS feature, but it keeps the tree correct. The downside is that it uses a lot of additional memory. I've now refactored the parser so that it's completely incremental and uses COWStrings from the standard library so that it returns a slice of the input instead. On top of it, I added a new way to take care of the nesting of blocks so you still can't get it wrong but we don't allocate memory. Now, the parser object borrows (mutably) another one so you can't use the original. It keeps track when you drop it of which blocks are open.
• SimonSapin: I'm in the middle of porting Servo to it. It's a little different so there's a bit of rewrite, but it simplifies things since you can just have simple parsing functions that consume only what they need, and if they don't find it they don't consume anything. So, you don't have to keep track of how many component values you've consumed. Just use try!. It makes the Servo parsing code much easier to read and write. I'm chasing down bugs, but hopefully it will be ready to land soon. Because it affects pretty much all the parsing code, I'd like to freeze it for a while once we start trying to land it.
• pcwalton: Fine by me.

Memory corruption

• larsberg: It wasn't clear to me whether the root cause was unsafe code, a compiler bug, or something else. I want to make sure if there's a compiler bug that we filed it, or if there's some library code or unsafe code that caused it, that we fix that.
• jdm: gw was looking to make a reproducible test case but I don't think that succeeded. We didn't track it down to a particular compiler issue or anything. There's an issue filed on hyper but with no known root cause.
• larsberg: I'll follow up with gw later. With the next rustup we'll be close enough to rust master that our compiler bug reports will probably be useful.

Rust alpha

• larsberg: I created a snapshot that is (almost) identical to the Rust 1.0 alpha. We're ready to start upgrading to that version as soon as someone wants to open branches and jump in. SimonSapin, should we wait on that until the parser fixes land?
• SimonSapin: If you get to the point where you need to touch the style components, talk to me before you do anything.
• brson: I'm afraid that with the rush to land features for alpha, we may have introduced more bugs than normal.
• larsberg: We can try to help identify those. Hopefully that will help get any bugs fixed before the first beta.
• SimonSapin: How many breaking changes should we expect from now on?
• brson: From now on, it should be (mostly?) just libraries.
• jack: Can we land pcwalton's PRs before the upgrade?
• mbrubeck: I have 4 in my review queue, should have them done today or tomorrow.
• pcwalton: Need to be in by the end of March; there's time before then.

Compiler errors

• manish: I've been looking into how to improve compiler errors with some pluggability. If you have any cryptic errors, I'll see if there's something we can improve on.