Tracking issue for Rust high-pri or blocking issues for Servo & Gecko

[larsbergstrom]

This issue will track all of the high-priority or blocking issues that Servo currently is waiting on in Rust. Issues created in Rust should reference this issue, and this top comment will be updated with links to those issues.

Rust

Bugs

• rust-lang/rust#32049 frequently breaks building on ARM32
• rust-lang/rfcs#788 return value optimization
• ARM target builds always omit frame pointer, making debugging/profiling awkward

Faster incremental builds

rust-lang/rust#27840

Optimized representations

rust-lang/rfcs#317

Cross memory-model data

rust-lang/rfcs#318

Virtual structs

jdm's requirements: https://gist.github.com/jdm/9900569
Leading current proposal: rust-lang/rfcs#349

Expose variadic functions to C

Right now, we work around it with a manual wrapper:
https://github.com/servo/servo/blob/master/ports/gonk/src/native_window_glue.cpp#L19-L22

Integer overflow

We'd love to at least have it per-crate, but honestly we'd consider shipping with it on by default.
rust-lang/cargo#2262
and: http://robert.ocallahan.org/2016/02/rewrite-everything-in-rust.html: we should try to make Rust release builds check for integer overflow by default.

Cargo

• rust-lang/cargo#2122 to share a single toplevel project (and only have a single Cargo.lock file!)
• rust-lang/cargo#1106 would make it possible to debug failures in build.rs files without modifying the submodules to print more output
• rust-lang/cargo#1997 would provide artifact caching and speed up CI builds
• rust-lang/cargo#942 would make it easier to handle a temporary override
• rust-lang/cargo#1744 would make it easier to build Servo with < 4GB of RAM and avoid some excessive CPU contention

Rustdoc

• rust-lang/rust#16358 (rustdoc linking issues)

[kmcallister]

The fix for rust-lang/rust#15750 looks good! There are a few cases it still doesn't handle properly (see rust-lang/rust#16617) but I was able to work around all of those.

[kmcallister]

No longer blocking on rust-lang/rust#16643; desugaring the for loop myself is a fine workaround for now.

[metajack]

rust#14344 isn't fixed yet, but we appear to have found a workaround so it is not blocking anything.

[SimonSapin]

Today’s Rust upgrade is blocked on rust-lang/rust#18659

[kmcallister]

rust-lang/rust#18671 is no longer blocking.

[jdm]

rust-lang/rust#19318 is killing me right now.

[tshepang]

Wouldn't rust-lang/cargo#1171 be worked-around by getting packages from crates.io instead of from git?

[SimonSapin]

@tshepang crates.io has a size limit on packages, 10 MB I believe. A Skia checkout (not counting the git repository) is ~45 MB.

[tshepang]

Wow, that package is very very not-small. Thanks for the info.

[SimonSapin]

The current Rust upgrade is blocked on one of rust-lang/rust#21883 or rust-lang/rust#21884 being fixed. (I’d prefer the latter. The former is just one instance of this problem, there might be other I haven’t found yet.)

[Manishearth]

Chris and some others fixed the stability of hash and time, I added a check to ensure that doesn't happen again. It isn't perfect, but we can also bypass this using !#[feature(unmarked_api)] (rust-lang/rust#21910)

[Manishearth]

Gonk blocker: rust-lang/cargo#1293

[Manishearth]

Not a blocker (until next week), but rust-lang/cargo#1351

[SimonSapin]

rust-lang/rust#23338 has a work-around, but happens a lot and gets tedious.

[kmcallister]

html5ever is hitting rust-lang/rust#23407

[metajack]

rust-lang/rust#23488 prevents us from having good performance monitoring on linux
and
rust-lang/cargo#1432 prevents us from setting debug=true to work around the problem

[kmcallister]

html5ever keeps running into rust-lang/rust#23110 in the test suite.

[kmcallister]

Servo's #2385 (compile-fail tests) is ever more of a concern as our plugins grow more magical. The upstream ticket is rust-lang/rust#12335.

[jdm]

@kmcallister https://github.com/laumann/compiletest-rs exists and #5646 is tracking integrating it.

[kmcallister]

Cool.

[Manishearth]

Rust-in-Gecko blocker: rust-lang/rust#25342 (Alex/Felix are already aware of it)

[SimonSapin]

rust-lang/rust#25748 will block the next rustup (unless we find at least a work around).

[SimonSapin]

rust-lang/cargo#1897 blocks cargoup (#7049).

[Manishearth]

rust-lang/rust#28559 blocks rustup

[mbrubeck]

rust-lang/rust#28924 blocks #7933

[SimonSapin]

I want to make changes (servo/rust-cssparser#90) that trigger rust-lang/rust#28934, and so would block our next rustup.

[SimonSapin]

rust-lang/libc#70 blocks #8446 (probably)

[alexcrichton]

As an update on the Cargo side of things, of the issues that're mentioned here:

• rust-lang/cargo#942 -- this is implemented in rust-lang/cargo#2385 (not landed)
• rust-lang/cargo#1007 -- this is implemented in rust-lang/cargo#2328 (not landed)
• rust-lang/cargo#1106 -- There's been some recent discussion on this and I think that we're getting to the point where a nice balance is struck. It won't take too long to implement I think but the hard part here is figuring out something within the design constraints.
• rust-lang/cargo#1744 -- I also have no plans for this, unfortunately, but it may also be worth looking into other mechanisms to automatically limit parallelism. For example job objects look promising on Windows and containers on Unix work somehow, may be worth piggybacking on that. Like a distributed crate cache, this seems like a nice to have though rather than a blocking issue?
• rust-lang/cargo#1997 -- I don't have any plans for this, and it unfortunately seems too vague to be actionable in the near term. This seems like a "nice to have" though rather than a blocking issue?
• rust-lang/cargo#2122 -- I hope to get around to designing this over the next week or two, it will likely manifest itself in the form of an RFC

[larsbergstrom]

Thanks for the update! Things look great overall.

You're right that we can wait on the other two. Some clarifying comments below, but I don't have any pushback on punting them.

• We can certainly wait on rust-lang/cargo#1744 - it mainly manifests as unintelligible build breaks ("Permission denied" while building Servo) for contributors with machines without < 4GB of RAM. We've gotten pretty used to seeing and commenting on it (just use "./mach build -j 1"), so it's not super urgent.
• I suspect that if Cargo/rustc do not provide a solution for caching files in the target directory for rust-lang/cargo#1997, the Gecko team will probably just extend their sccache tool to wrap calls to rustc to copy down cached output files.

[aturon]

@larsbergstrom Regarding caching, I think part of the problem is a lack of clarity about the design constraints/requirements. At some point, we can more aggressively seek them out. But it's not obvious to me when the right timing is, or whether e.g. it's best to let Gecko try to find their own way first. (It's not clear whether a naive wrapping of rustc will do the trick.)

Any sense on when this is likely to become a real issue? I would assume not until they're building a serious amount of Rust code?

[larsbergstrom]

@aturon I'll ask around. I suspect that it depends on whether or not Rust/Cargo "behave well" with the new artifact builds in Firefox (https://groups.google.com/forum/#!topic/mozilla.dev.builds/jGg69m0x6Ck ). That is, can we just download all of the prebuilt files in the object dir and have things work?

CC @ncalexan (who did much of that work).

[ncalexan]

@larsbergstrom this ticket is pretty broad, and the discussion of caching doesn't really say what you want to do. Artifact builds download the major compiled libraries from Mozilla's automation; the big one is libxul.so. I have only followed the rustc integration at a distance, but it's my understanding that y'all produce .o files that are linked into existing libraries (including libxul.so). If that's true, then any Rust integration into the Gecko tree should "just work" with artifact builds. (Of course, Rust developers won't be able to get the speed advantages of artifact builds, but that'll teach you to use a compiler :))

@rillian is the person I tap to keep abreast of Rust/Gecko integration progress -- perhaps he can add color here?

[larsbergstrom]

@ncalexan Sorry about that! I'll move the convo out of the metabug off to where it should be (rust-lang/cargo#1997).

[larsbergstrom]

Most of the Servo-critical stuff here has been fixed.

Issues relevant to using Rust/Cargo in Gecko have been moved to an internal google doc.