add lint for `unsafe` blocks
tutorial: alternatives to ownership

This replaces the old section on managed pointers because the syntax is
going to be removed and it's currently feature gated so the examples
don't work out-of-the-box. Dynamic mutability coverage can be added
after the `Mut<T>` work has landed.
auto merge of #10589 : thestinger/rust/doc, r=pcwalton



This replaces the old section on managed pointers because the syntax is
going to be removed and it's currently feature gated so the examples
don't work out-of-the-box. Dynamic mutability coverage can be added
after the `Mut<T>` work has landed.
auto merge of #10599 : thestinger/rust/unsafe, r=cmr

This is just meant to be for containing usage of `unsafe`, much like `heap_memory`.
std::rand: move TaskRng off @mut.

Replace with some unsafe code by storing a pointer into TLS-owned heap
data.
auto merge of #10588 : huonw/rust/un@mutilate-task_rng, r=alexcrichton

Replace with some unsafe code by storing a pointer into TLS-owned heap
data.
test: test that the `unsafe_block` lint picks up `unsafe` blocks in
macros.
auto merge of #10582 : g3xzh/rust/master, r=cmr

More new benchmark tests. some of them are benchmarking `starts_with` and `ends_with`.
Let me know if I am missing something.
Thanks in advance.
mention `Gc` in the managed box feature gate
minor rewording in the tutorial's `Rc` coverage
syntax: add a visit_ident method to the Visitor.
auto merge of #10606 : huonw/rust/lint-unsafe-in-macro, r=thestinger

Add a test for the case I mentioned on #10599.
auto merge of #10608 : thestinger/rust/managed, r=huonw
add a breakpoint intrinsic for debugging

This can be used to grab the attention of a debugger, and unlike
`abort` execution can be resumed.
auto merge of #10610 : thestinger/rust/breakpoint, r=pnkfelix

This can be used to grab the attention of a debugger, and unlike
`abort` execution can be resumed.
The original fixme #2699 was removed back in PR #6053.

I cannot tell whether the original comment was unsure about the
arithmetic calculations, or if it was unsure about the assumptions
being made about the alignment of the current allocation pointer.

The arithmetic calculation looks fine to me, though.  This technique
is documented e.g. in Henry Warren's "Hacker's Delight" (section 3-1).

(I am sure one can find it elsewhere too, its not an obscure
property.)
Move more of the exportation burden into privacy

I added a test case which does not compile today, and required changes on
privacy's side of things to get right. Additionally, this moves a good bit of
logic which did not belong in reachability into privacy.

All of reachability should solely be responsible for determining what the
reachable surface area of a crate is given the exported surface area (where the
exported surface area is that which is usable by external crates).

Privacy will now correctly figure out what's exported by deeply looking
through reexports. Previously if a module were reexported under another name,
nothing in the module would actually get exported in the executable. I also
consolidated the phases of privacy to be clearer about what's an input to what.
The privacy checking pass no longer uses the notion of an "all public" path, and
the embargo visitor is no longer an input to the checking pass.

Currently the embargo visitor is built as a saturating analysis because it's
unknown what portions of the AST are going to get re-exported.
auto merge of #10583 : alexcrichton/rust/privacy-reexport, r=pcwalton

I added a test case which does not compile today, and required changes on
privacy's side of things to get right. Additionally, this moves a good bit of
logic which did not belong in reachability into privacy.

All of reachability should solely be responsible for determining what the
reachable surface area of a crate is given the exported surface area (where the
exported surface area is that which is usable by external crates).

Privacy will now correctly figure out what's exported by deeply looking
through reexports. Previously if a module were reexported under another name,
nothing in the module would actually get exported in the executable. I also
consolidated the phases of privacy to be clearer about what's an input to what.
The privacy checking pass no longer uses the notion of an "all public" path, and
the embargo visitor is no longer an input to the checking pass.

Currently the embargo visitor is built as a saturating analysis because it's
unknown what portions of the AST are going to get re-exported.

This also cracks down on exported methods from impl blocks and trait blocks. If you implement a private trait, none of the symbols are exported, and if you have an impl for a private type none of the symbols are exported either. On the other hand, if you implement a public trait for a private type, the symbols are still exported. I'm unclear on whether this last part is correct, but librustc will fail to link unless it's in place.
auto merge of #10612 : pnkfelix/rust/remove-cut-and-pasted-rt-fixme, r=pcwalton

I cannot tell whether the original comment was unsure about the
arithmetic calculations, or if it was unsure about the assumptions
being made about the alignment of the current allocation pointer.

The arithmetic calculation looks fine to me, though.  This technique
is documented e.g. in Henry Warren's "Hacker's Delight" (section 3-1).

(I am sure one can find it elsewhere too, its not an obscure
property.)
Put non-ascii identifiers behind a feature gate.

cf. https://mail.mozilla.org/pipermail/rust-dev/2013-November/006920.html