Make fn pub for windows compatibility
auto merge of #9986 : thestinger/rust/float, r=cmr

copysign, ring, nearbyint, round
Remove rusti reference from pp.mk
Propagate reachability through reexported impls

When re-exporting a trait/structure/enum, then we need to propagate the
reachability of the type through the methods that are defined on it.

Closes #9906
Closes #9968
rustpkg: Search for crates in the current directory

As per #8520, find crates in the current working directory even
if it's not a workspace.

Closes #8520
rustdoc: Don't overflow long type/module names

Closes #9862
auto merge of #9736 : catamorphism/rust/rustpkg-issue-8520, r=cmr

r? @cmr As per #8520, find crates in the current working directory even
if it's not a workspace.

Closes #8520
fix the new floating point intrinsics
Register snapshots
rustdoc: Render default methods for impls as well

This does not work for cross-crate implementations of traits. Cross-crate
implementations are a separate issue that should be addressed separately.
Basically when an implementation of an external trait is detected, the trait
would have to be loaded at that time (or possibly sooner...). Rustdoc currently
doesn't have the proper infrastructure for adding this.

Closes #9985
cc #9999
std: Move sys::log_str to repr::repr_to_str. Further work on #2240.
auto merge of #9997 : thestinger/rust/float, r=thestinger
syntax: Add the Bug Report HOWTO URL to the ICE message

And also reference the bug report HOWTO in CONTRIBUTING.md
Add support for nested comments

Fixes #9468.
auto merge of #10000 : cmr/rust/snapshot, r=alexcrichton
auto merge of #9936 : madjar/rust/master, r=alexcrichton

This should close #9468.

I removed the test stating that nested comments should not be implemented.

I had a little chicken-and-egg problem because a comment of the std contains "/*", and adding support for nested comment creates a backward incompatibility in that case, so I had to use a dirty hack to get stage1 and stage2 to compile. This part should be revert when this commit lands in a snapshot.

This is my first non-typo contribution, so I'm open to any comment.
auto merge of #9937 : brson/rust/log_str, r=alexcrichton
auto merge of #9960 : adridu59/rust/patch-doc-limited, r=alexcrichton

This is #9868 but doesn't move css files to a separate subfolder, which was causing errors on the Rust buildbot.

@alexcrichton
auto merge of #9982 : danluu/rust/local_delc_xfail, r=brson

This patch is trivial, but it comes with a question. Does Mozilla need to own the copyright on code submitted to Rust?

The reason I ask is that, since the last time I submitted anything to a Mozilla project, I started working at Google, and they (by default) own the copyright on code that I write (even in my spare time). There's a process to assign copyright to another entity, and it should be a formality for something like this, but I'd still have to go through it if that's a requirement for Rust.

Anyway, I'm submitting this incredibly trivial thing because, if I have to go through that process for the first time, I'd like it to be for something that's trivial, so I can see how much of a hassle it is (if any) without having invested much time up front.

I didn't see anything about copyright in the Mozilla contributor's agreement, but I could have easily missed something somewhere else.
auto merge of #9992 : astrieanna/rust/rm_rusti, r=alexcrichton

It seems like rusti has been removed, except for one reference in one Makefile. This reference breaks building rust on my computer because the "all-target" rule has rusti as a target.

~~~~
make: *** No rule to make target `x86_64-unknown-linux-gnu/stage2/bin/rusti', needed by `all-target-x86_64-unknown-linux-gnu-host-x86_64-unknown-linux-gnu'.  Stop.
~~~~

Removing this line fixes things for me.