mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
61,259 Commits 2 Branches 0 Tags 1.4 GiB
e32e2d47d0
Commit Graph

61259 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Corey Farwell
e32e2d47d0 Rollup merge of #39602 - estebank:fix-39544, r=eddyb 
Fix ICE when accessing mutably an immutable enum

Fix #39544.
 2017-02-09 08:47:34 -05:00
Corey Farwell
f447c2b443 Rollup merge of #39601 - dumbbell:update-liblibc-to-include-aarch64-unknown-freebsd, r=alexcrichton 
liblibc: Update to include `aarch64-unknown-freebsd` support
 2017-02-09 08:47:33 -05:00
Corey Farwell
15decb86b2 Rollup merge of #39595 - camlorn:structured_repr, r=eddyb 
Make reprs use a structured representation instead of a slice

This is needed for `-z reorder-fields`.  The old design uses a slice taken from HIR, plus a cache that lazily parses.  The new design stores it directly in the `AdtDef` as a `ReprOptions`.  We're doing this now because we need to be able to add reprs that don't necessarily exist in HIR for `-z reorder-fields`, but it needs to happen anyway.

`lookup_repr_hints` should be mostly deprecated.  I want to remove it from `layout` before closing this, unless people think that should be a separate PR.  The `[WIP]` is because of this.  The problem with closing this as-is is that the code here isn't actually testable until some parts of the compiler start using it.

r? @eddyb
 2017-02-09 08:47:32 -05:00
bors
b0e46f03d8 Auto merge of #39586 - arielb1:packed-values, r=eddyb 
emit "align 1" metadata on loads/stores of packed structs

According to the LLVM reference:
> A value of 0 or an omitted align argument means that the operation has
the ABI alignment for the target.

So loads/stores of fields of packed structs need to have their align set
to 1. Implement that by tracking the alignment of `LvalueRef`s.

Fixes #39376.

r? @eddyb
 2017-02-09 09:02:43 +00:00
bors
fd2f8a4536 Auto merge of #39677 - frewsxcv:rollup, r=frewsxcv 
Rollup of 9 pull requests

- Successful merges: #37928, #38699, #39589, #39598, #39599, #39641, #39649, #39653, #39671
- Failed merges:
 2017-02-09 05:58:29 +00:00
Corey Farwell
1e3e904101 Rollup merge of #39671 - alexcrichton:change-order, r=brson 
travis: Fix build order of dist-x86-linux

I just tried to build this container locally but it looks like connecting to
ftp.gnu.org requires SNI, so let's build curl/OpenSSL first to ensure that we've
got an SNI-capable client to download gcc/binutils with.
 2017-02-08 23:55:51 -05:00
Corey Farwell
44fdf5bcd7 Rollup merge of #39653 - JanZerebecki:test-issue-27433, r=alexcrichton 
Add test for #27433
 2017-02-08 23:55:50 -05:00
Corey Farwell
4f8adb6831 Rollup merge of #39649 - GuillaumeGomez:join_paths-url, r=frewsxcv 
Add missing urls on join_paths

r? @frewsxcv
 2017-02-08 23:55:49 -05:00
Corey Farwell
ab7e51b2f7 Rollup merge of #39641 - Ms2ger:purge-mk, r=alexcrichton 
Remove some leftover makefiles.
 2017-02-08 23:55:48 -05:00
Corey Farwell
9f2795f7bd Rollup merge of #39599 - alexcrichton:cargo-tarball-name, r=brson 
Fix a manifest-generation bug on beta

Right now all Cargo release tarballs are 'nightly', they're not on the standard
channels yet.
 2017-02-08 23:55:47 -05:00
Corey Farwell
a7017b582c Rollup merge of #39598 - alexcrichton:cargo-branch, r=brson 
Fix branch name Cargo's downloaded from

This landed on beta in #39546 and this is bringing the patch back to master.
 2017-02-08 23:55:45 -05:00
Corey Farwell
4f6868aa01 Rollup merge of #39589 - ollie27:rustdoc_impl_disambiguation, r=alexcrichton 
rustdoc: Improve impl disambiguation

* Don't disambiguate if there are multiple impls for the same type.
* Disambiguate for impls of &Foo and &mut Foo.
* Don't try to disambiguate generic types.

[before](https://doc.rust-lang.org/nightly/std/ops/trait.Rem.html#implementors) [after](https://ollie27.github.io/rust_doc_test/std/ops/trait.Rem.html#implementors)
 2017-02-08 23:55:44 -05:00
Corey Farwell
3053494a9a Rollup merge of #38699 - japaric:lsan, r=alexcrichton 
LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support

```
$ cargo new --bin leak && cd $_

$ edit Cargo.toml && tail -n3 $_
```

``` toml
[profile.dev]
opt-level = 1
```

```
$ edit src/main.rs && cat $_
```

``` rust
use std::mem;

fn main() {
    let xs = vec![0, 1, 2, 3];
    mem::forget(xs);
}
```

```
$ RUSTFLAGS="-Z sanitizer=leak" cargo run --target x86_64-unknown-linux-gnu; echo $?
    Finished dev [optimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/leak`

=================================================================
==10848==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x557c3488db1f in __interceptor_malloc /shared/rust/checkouts/lsan/src/compiler-rt/lib/lsan/lsan_interceptors.cc:55
    #1 0x557c34888aaa in alloc::heap::exchange_malloc::h68f3f8b376a0da42 /shared/rust/checkouts/lsan/src/liballoc/heap.rs:138
    #2 0x557c34888afc in leak::main::hc56ab767de6d653a $PWD/src/main.rs:4
    #3 0x557c348c0806 in __rust_maybe_catch_panic ($PWD/target/debug/leak+0x3d806)

SUMMARY: LeakSanitizer: 16 byte(s) leaked in 1 allocation(s).
23
```

```
$ cargo new --bin racy && cd $_

$ edit src/main.rs && cat $_
```

``` rust
use std::thread;

static mut ANSWER: i32 = 0;

fn main() {
    let t1 = thread::spawn(|| unsafe { ANSWER = 42 });
    unsafe {
        ANSWER = 24;
    }
    t1.join().ok();
}
```

```
$ RUSTFLAGS="-Z sanitizer=thread" cargo run --target x86_64-unknown-linux-gnu; echo $?
==================
WARNING: ThreadSanitizer: data race (pid=12019)
  Write of size 4 at 0x562105989bb4 by thread T1:
    #0 racy::main::_$u7b$$u7b$closure$u7d$$u7d$::hbe13ea9e8ac73f7e $PWD/src/main.rs:6 (racy+0x000000010e3f)
    #1 _$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h2e466a92accacc78 /shared/rust/checkouts/lsan/src/libstd/panic.rs:296 (racy+0x000000010cc5)
    #2 std::panicking::try::do_call::h7f4d2b38069e4042 /shared/rust/checkouts/lsan/src/libstd/panicking.rs:460 (racy+0x00000000c8f2)
    #3 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56)
    #4 std::panic::catch_unwind::h31ca45621ad66d5a /shared/rust/checkouts/lsan/src/libstd/panic.rs:361 (racy+0x00000000b517)
    #5 std:🧵:Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::hccfc37175dea0b01 /shared/rust/checkouts/lsan/src/libstd/thread/mod.rs:357 (racy+0x00000000c226)
    #6 _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::hd880bbf91561e033 /shared/rust/checkouts/lsan/src/liballoc/boxed.rs:605 (racy+0x00000000f27e)
    #7 std::sys:👿🧵:Thread:🆕:thread_start::hebdfc4b3d17afc85 <null> (racy+0x0000000abd40)

  Previous write of size 4 at 0x562105989bb4 by main thread:
    #0 racy::main::h23e6e5ca46d085c3 $PWD/src/main.rs:8 (racy+0x000000010d7c)
    #1 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56)
    #2 __libc_start_main <null> (libc.so.6+0x000000020290)

  Location is global 'racy::ANSWER::h543d2b139f819b19' of size 4 at 0x562105989bb4 (racy+0x0000002f8bb4)

  Thread T1 (tid=12028, running) created by main thread at:
    #0 pthread_create /shared/rust/checkouts/lsan/src/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:902 (racy+0x00000001aedb)
    #1 std::sys:👿🧵:Thread:🆕:hce44187bf4a36222 <null> (racy+0x0000000ab9ae)
    #2 std:🧵:spawn::he382608373eb667e /shared/rust/checkouts/lsan/src/libstd/thread/mod.rs:412 (racy+0x00000000b5aa)
    #3 racy::main::h23e6e5ca46d085c3 $PWD/src/main.rs:6 (racy+0x000000010d5c)
    #4 __rust_maybe_catch_panic <null> (racy+0x0000000b4e56)
    #5 __libc_start_main <null> (libc.so.6+0x000000020290)

SUMMARY: ThreadSanitizer: data race $PWD/src/main.rs:6 in racy::main::_$u7b$$u7b$closure$u7d$$u7d$::hbe13ea9e8ac73f7e
==================
ThreadSanitizer: reported 1 warnings
66
```

```
$ cargo new --bin oob && cd $_

$ edit src/main.rs && cat $_
```

``` rust
fn main() {
    let xs = [0, 1, 2, 3];
    let y = unsafe { *xs.as_ptr().offset(4) };
}
```

```
$ RUSTFLAGS="-Z sanitizer=address" cargo run --target x86_64-unknown-linux-gnu; echo $?
=================================================================
==13328==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff29f3ecd0 at pc 0x55802dc6bf7e bp 0x7fff29f3ec90 sp 0x7fff29f3ec88
READ of size 4 at 0x7fff29f3ecd0 thread T0
    #0 0x55802dc6bf7d in oob::main::h0adc7b67e5feb2e7 $PWD/src/main.rs:3
    #1 0x55802dd60426 in __rust_maybe_catch_panic ($PWD/target/debug/oob+0xfe426)
    #2 0x55802dd58dd9 in std::rt::lang_start::hb2951fc8a59d62a7 ($PWD/target/debug/oob+0xf6dd9)
    #3 0x55802dc6c002 in main ($PWD/target/debug/oob+0xa002)
    #4 0x7fad8c3b3290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
    #5 0x55802dc6b719 in _start ($PWD/target/debug/oob+0x9719)

Address 0x7fff29f3ecd0 is located in stack of thread T0 at offset 48 in frame
    #0 0x55802dc6bd5f in oob::main::h0adc7b67e5feb2e7 $PWD/src/main.rs:1

  This frame has 1 object(s):
    [32, 48) 'xs' <== Memory access at offset 48 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow $PWD/src/main.rs:3 in oob::main::h0adc7b67e5feb2e7
Shadow bytes around the buggy address:
  0x1000653dfd40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfd50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfd60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfd70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000653dfd90: 00 00 00 00 f1 f1 f1 f1 00 00[f3]f3 00 00 00 00
  0x1000653dfda0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfdb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfdc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfdd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000653dfde0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==13328==ABORTING
1
```

```
$ cargo new --bin uninit && cd $_

$ edit src/main.rs && cat $_
```

``` rust
use std::mem;

fn main() {
    let xs: [u8; 4] = unsafe { mem::uninitialized() };
    let y = xs[0] + xs[1];
}
```

```
$ RUSTFLAGS="-Z sanitizer=memory" cargo run; echo $?
==30198==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x563f4b6867da in uninit::main::hc2731cd4f2ed48f8 $PWD/src/main.rs:5
    #1 0x563f4b7033b6 in __rust_maybe_catch_panic ($PWD/target/debug/uninit+0x873b6)
    #2 0x563f4b6fbd69 in std::rt::lang_start::hb2951fc8a59d62a7 ($PWD/target/debug/uninit+0x7fd69)
    #3 0x563f4b6868a9 in main ($PWD/target/debug/uninit+0xa8a9)
    #4 0x7fe844354290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
    #5 0x563f4b6864f9 in _start ($PWD/target/debug/uninit+0xa4f9)

SUMMARY: MemorySanitizer: use-of-uninitialized-value $PWD/src/main.rs:5 in uninit::main::hc2731cd4f2ed48f8
Exiting
77
```
 2017-02-08 23:55:43 -05:00
Corey Farwell
7f7dc764f5 Rollup merge of #37928 - chriskrycho:document-rfc-1623, r=steveklabnik 
Document RFC 1623: static lifetime elision.

This should be the last item required for stabilizing RFC 1623 (#35897).
 2017-02-08 23:55:42 -05:00
Jorge Aparicio
e180dd541a sanitizer-dylib: only run where std for x86_64-linux is available 2017-02-08 22:58:53 -05:00
Alex Crichton
8fc0b37428 travis: Fix build order of dist-x86-linux 
I just tried to build this container locally but it looks like connecting to
ftp.gnu.org requires SNI, so let's build curl/OpenSSL first to ensure that we've
got an SNI-capable client to download gcc/binutils with.
 2017-02-08 17:13:46 -08:00
Jorge Aparicio
78a11f1b97 fix the sanitizer-dylib test on non x86_64 linux hosts 2017-02-08 18:51:43 -05:00
Jorge Aparicio
1914c8e0ac dist-x86-linux: install newer kernel headers 2017-02-08 18:51:43 -05:00
Jorge Aparicio
47ae2393e6 enable sanitizers on build job that tests x86_64 linux 2017-02-08 18:51:43 -05:00
Jorge Aparicio
72058e4f4c enable sanitizers on x86_64-linux releases 2017-02-08 18:51:43 -05:00
Jorge Aparicio
22097e6827 use helper function in the rebuild logic of the rustc_*san crates 2017-02-08 18:51:43 -05:00
Jorge Aparicio
775a93646c build/test the sanitizers only when --enable-sanitizers is used 2017-02-08 18:51:43 -05:00
Jorge Aparicio
9af6aa3889 sanitizer support 2017-02-08 18:51:43 -05:00
Ariel Ben-Yehuda
d71988a1d4 pacify tidy 2017-02-08 22:23:21 +01:00
Ariel Ben-Yehuda
3652c095ce address review comments 2017-02-08 22:23:21 +01:00
Ariel Ben-Yehuda
ffcfdcfe4c Inline the function with_lvalue_ref into trans_transmute 
The function was a footgun because it created `undef` references to
ZSTs, which could cause trouble were they to leak to user code.
 2017-02-08 22:23:21 +01:00
Ariel Ben-Yehuda
7ce1f5194c remove unneeded drop of isize 2017-02-08 22:23:21 +01:00
Ariel Ben-Yehuda
09825de61b emit "align 1" metadata on loads/stores of packed structs 
According to the LLVM reference:
> A value of 0 or an omitted align argument means that the operation has
the ABI alignment for the target.

So loads/stores of fields of packed structs need to have their align set
to 1. Implement that by tracking the alignment of `LvalueRef`s.

Fixes #39376.
 2017-02-08 22:23:21 +01:00
Guillaume Gomez
3022614ec3 Add missing urls on join_paths 2017-02-08 21:53:49 +01:00
Jan Zerebecki
ab3da97615 Add test for #27433 2017-02-08 21:51:35 +01:00
bors
29dece1c8b Auto merge of #39523 - alexcrichton:fpic, r=aturon 
Pass -fPIC to native compiles on 32-bit

This is apparently a regression from 1.14.0 to 1.15.0. Previously we
passed `-fPIC` to C compilers on i686 targets, but the `gcc` crate
apparently [explicitly] didn't do this. I don't recall why that was
avoided but it was [previously passed by the makefiles][mk] and this
seems to have [caused a regression][regression] in Firefox, so this
commit reverts back to passing `-fPIC`.

[explicitly]: https://github.com/alexcrichton/gcc-rs/commit/362bdf20
[mk]: https://github.com/rust-lang/rust/blob/c781fc4a/mk/cfg/i686-unknown-linux-gnu.mk#L11
[regression]: https://bugzilla.mozilla.org/show_bug.cgi?id=1336155
 2017-02-08 20:49:24 +00:00
Chris Krycho
4096dd684c Add more examples, get everything passing at last. 2017-02-08 14:30:31 -05:00
bors
4379e2fa08 Auto merge of #39645 - frewsxcv:rollup, r=frewsxcv 
Rollup of 11 pull requests

- Successful merges: #39462, #39512, #39529, #39557, #39561, #39582, #39583, #39597, #39622, #39624, #39630
- Failed merges:
 2017-02-08 18:11:06 +00:00
Corey Farwell
62d22678d4 Rollup merge of #39630 - alexcrichton:update-manifest, r=brson 
Rename manifest_version to manifest-version

The current manifests encode this with a dash in the name, so we should preserve
that!
 2017-02-08 10:19:59 -05:00
Corey Farwell
83a581cadb Rollup merge of #39624 - brson:relnotes-master, r=alexcrichton 
Bump stable release date

cc https://github.com/rust-lang/rust/pull/39623
 2017-02-08 10:19:58 -05:00
Corey Farwell
e15bd3177e Rollup merge of #39622 - alexcrichton:clean-dist, r=brson 
rustbuild: Clean build/dist on `make clean`

Prevents stale artifacts from sticking around by accident!
 2017-02-08 10:19:57 -05:00
Corey Farwell
722baed173 Rollup merge of #39597 - GuillaumeGomez:correct_rustdoc_test_file, r=alexcrichton 
Display correct filename with --test option

Fixes #39592.

With the current files:

```rust
pub mod foo;

/// This is a Foo;
///
/// ```
/// println!("baaaaaar");
/// ```
pub struct Foo;

/// This is a Bar;
///
/// ```
/// println!("fooooo");
/// ```
pub struct Bar;
```

```rust
// note the whitespaces
/// ```
/// println!("foo");
/// ```
pub fn foo() {}
```

It displays:

```
./build/x86_64-apple-darwin/stage1/bin/rustdoc --test test.rs

running 3 tests
test test.rs - line 13 ... ok
test test.rs - line 5 ... ok
test foo.rs - line 2 ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured
```

```

` ``
println!("lol");
` ``

asdjnfasd

asd
```

It displays:

```
./build/x86_64-apple-darwin/stage1/bin/rustdoc --test foo.md

running 1 test
test <input> - line 3 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
```

r? @alexcrichton
 2017-02-08 10:19:55 -05:00
Corey Farwell
7658921267 Rollup merge of #39583 - michaelwoerister:limit-llvm-threads, r=nikomatsakis 
back: Limit the number of LLVM worker threads.

This should fix issue https://github.com/rust-lang/rust/issues/39568.
Also see https://github.com/rust-lang/rust/issues/39280.

r? @nikomatsakis
 2017-02-08 10:19:54 -05:00
Corey Farwell
944933ef4e Rollup merge of #39582 - nikomatsakis:incr-comp-issue-39569, r=michaelwoerister 
Handle the case where an intermediate node can't be recreated

This solution grows the graph, but this is quite the corner case.

r? @michaelwoerister
 2017-02-08 10:19:52 -05:00
Corey Farwell
e0eeb6e637 Rollup merge of #39561 - phungleson:libcollectionsbench, r=alexcrichton 
Extract collections benchmarks to libcollections/bench

Good suggestion from @stjepang https://github.com/rust-lang/rust/issues/39484#issuecomment-277467765

r? @alexcrichton
 2017-02-08 10:19:51 -05:00
Corey Farwell
75f97db367 Rollup merge of #39557 - bjorn3:pp-docs, r=jseyfried 
A few documentation improvements for `syntax::print::pp`

* Moved algorithm explanation to module docs
* Added ``` before and after the examples
* Explanation of the `rbox`, `ibox` and `cbox` names
* Added docs about the breaking types to `Breaks`
 2017-02-08 10:19:50 -05:00
Corey Farwell
7709c4d2b9 Rollup merge of #39529 - dylanmckay:llvm-4.0-align32, r=alexcrichton 
[LLVM 4.0] Use 32-bits for alignment

LLVM 4.0 changes this. This change is fine to make for LLVM 3.9 as we
won't have alignments greater than 2^32-1.
 2017-02-08 10:19:49 -05:00
Corey Farwell
96bf9ba94d Rollup merge of #39512 - oconnor663:try_wait, r=alexcrichton 
make Child::try_wait return io::Result<Option<ExitStatus>>

This is much nicer for callers who want to short-circuit real I/O errors
with `?`, because they can write this

    if let Some(status) = foo.try_wait()? {
        ...
    } else {
        ...
    }

instead of this

    match foo.try_wait() {
        Ok(status) => {
            ...
        }
        Err(err) if err.kind() == io::ErrorKind::WouldBlock => {
            ...
        }
        Err(err) => return Err(err),
    }

The original design of `try_wait` was patterned after the `Read` and
`Write` traits, which support both blocking and non-blocking
implementations in a single API. But since `try_wait` is never blocking,
it makes sense to optimize for the non-blocking case.

Tracking issue: https://github.com/rust-lang/rust/issues/38903
 2017-02-08 10:19:48 -05:00
Corey Farwell
f69259ecf8 Rollup merge of #39462 - emilio:improper-ctypes, r=nikomatsakis 
lint/ctypes: Don't warn on sized structs with PhantomData.

Fixes #34798
 2017-02-08 10:19:47 -05:00
Ms2ger
52a887e12b Remove some leftover makefiles. 2017-02-08 10:56:42 +01:00
Guillaume Gomez
d2f8abf254 Add more test for rustdoc --test 2017-02-08 10:10:06 +01:00
bors
10f6a5c443 Auto merge of #39638 - frewsxcv:rollup, r=frewsxcv 
Rollup of 13 pull requests

- Successful merges: #38764, #39361, #39372, #39374, #39400, #39426, #39431, #39459, #39482, #39545, #39593, #39620, #39621
- Failed merges:
 2017-02-08 03:55:13 +00:00
Corey Farwell
0a815ac816 Rollup merge of #39621 - GuillaumeGomez:current_dir_docs, r=steveklabnik 
Add missing urls for current_dir

r? @steveklabnik
 2017-02-07 22:54:32 -05:00
Corey Farwell
68872a8a90 Rollup merge of #39620 - Gheoan:patch-1, r=steveklabnik 
add missing comma
 2017-02-07 22:54:30 -05:00
Corey Farwell
83595fa2f4 Rollup merge of #39593 - steveklabnik:bookshelf-landing-page, r=frewsxcv 
Re-write the doc index page

Clarify and reorganize.

Add the section for the bookshelf. More to come here in the near future!

Part of #39588
 2017-02-07 22:54:29 -05:00