This minimally changes rustdoc's search as described in #25167.
Additionally, I also cleaned up some parts of the JS code.
There is one more change I made: After each result for a primitive type, I added "(Overview of primitive type)". This further differentiates the result from the module (previously, the only difference was that the module's link was blue). I'm not this is the way to go (this seems to be the only place where we do this) and it's no problem for me to remove that commit.
cc @steveklabnik (it concerns docs) and @alexcrichton (who made changes to rustdoc previously)
Make the error message about missing dependencies clearer, since "need program file" is pretty confusing, and make full commands get logged, since that seems to have been the intention.
This "fast path" in `DirEntry::file_type` on Unix wasn't turning out to be so
much of a fast path as the `DT_DIR` case wasn't handled, so directories fell
back to using `lstat` instead. This commit adds the missing case to return
quickly if a path is a directory and `DirEntry::file_type` is used.
This was motivated by http://www.evanmiller.org/a-taste-of-rust.html.
A common problem when working with FFI right now is converting from raw
C strings into `&str` or `String`. Right now you're required to say
something like
let cstr = unsafe { CStr::from_ptr(ptr) };
let result = str::from_utf8(cstr.to_bytes());
This is slightly awkward, and is not particularly intuitive for people
who haven't used the ffi module before. We can do a bit better by
providing some convenience methods on CStr:
fn to_str(&self) -> Result<&str, str::Utf8Error>
fn to_string_lossy(&self) -> Cow<str>
This will make it immediately apparent to new users of CStr how to get a
string from a raw C string, so they can say:
let s = unsafe { CStr::from_ptr(ptr).to_string_lossy() };
The `debug_builders` feature is up for 1.1 stabilization in #24028. This commit stabilizes the API as-is with no changes.
Some nits that @alexcrichton mentioned that may be worth discussing now if anyone cares:
* Should `debug_tuple_struct` and `DebugTupleStruct` be used instead of `debug_tuple` and `DebugTuple`? It's more typing but is a technically more correct name.
* `DebugStruct` and `DebugTuple` have `field` methods while `DebugSet`, `DebugMap` and `DebugList` have `entry` methods. Should we switch those to something else for consistency?
cc @alexcrichton @aturon
The install target depends on compiler-docs but 'all' does not.
This means that running 'make && make install' will run additional
doc builds and tests during installation, which hides bugs in
the build.
For now this just unconditionally stops building compiler docs.
The install target depends on compiler-docs but 'all' does not.
This means that running 'make && make install' will run additional
doc builds and tests during installation, which hides bugs in
the build.
For now this just unconditionally stops building compiler docs.
A common problem when working with FFI right now is converting from raw
C strings into `&str` or `String`. Right now you're required to say
something like
let cstr = unsafe { CStr::from_ptr(ptr) };
let result = str::from_utf8(cstr.to_bytes());
This is slightly awkward, and is not particularly intuitive for people
who haven't used the ffi module before. We can do a bit better by
providing some convenience methods on CStr:
fn to_str(&self) -> Result<&str, str::Utf8Error>
fn to_string_lossy(&self) -> Cow<str>
This will make it immediately apparent to new users of CStr how to get a
string from a raw C string, so they can say:
let s = unsafe { CStr::from_ptr(ptr).to_string_lossy() };
There are more possible optimizations left (cached length in loops) as
well as some possible bugs (shadowed variables) to fix. This is mostly
syntactic.
The `run` function passed its argument to `msg` via `"$@"`, but `msg`
only printed its first argument. I think the intention was for `msg` to
print all its arguments. (If not, `run` should only `msg "$1"`.)
Took me a moment to figure out that the appropriate response to
"need program file" was to install the program named "file", not
to think "If I didn't need the program file, why would I be
compiling things?".
the "-c" option of head isn't a posix option, and it isn't supported
under openbsd.
prefer the use of cut -c 1-8 (which is posix) to extract the first 8
chars.
r? @alexcrichton
collections: Reorder slice methods to improve API docs
We have an evolutionary history whose traces are still visible in the
slice docs today.
Some heuristics:
* Group method and method_mut together
* Group method and method_by together
* Group by use case, here we have roughly:
Basic interrogators (len)
Mutation (swap)
Iterators (iter)
Segmentation (split)
Searching (contains)
Permutations (permutations)
Misc (clone_from_slice)
It is hard to find the actual unstable feature which caused the error when using a list of stable and unstable features as the span marks the whole line
```
src/k8055.rs:22:1: 22:64 error: unstable feature
src/k8055.rs:22 #![feature(slice_patterns, rustc_private, core, convert, libc)]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
This PR spawns an error for each unstable feature in the list:
```
est.rs:1:12: 1:26 error: unstable feature [-D unstable-features]
test.rs:1 #![feature(slice_patterns, rustc_private, core, convert, libc)]
^~~~~~~~~~~~~~
test.rs:1:28: 1:41 error: unstable feature [-D unstable-features]
test.rs:1 #![feature(slice_patterns, rustc_private, core, convert, libc)]
^~~~~~~~~~~~~
test.rs:1:43: 1:47 error: unstable feature [-D unstable-features]
test.rs:1 #![feature(slice_patterns, rustc_private, core, convert, libc)]
^~~~
test.rs:1:49: 1:56 error: unstable feature [-D unstable-features]
test.rs:1 #![feature(slice_patterns, rustc_private, core, convert, libc)]
^~~~~~~
test.rs:1:58: 1:62 error: unstable feature [-D unstable-features]
test.rs:1 #![feature(slice_patterns, rustc_private, core, convert, libc)]
^~~~
```
