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.
The change to split up soft_link to OS-specific symlink, symlink_file,
and symlink_dir didn't actually land in 1.0.0. Update the stability and
deprecation attributes to correctly indicate that these changes happend
in 1.1.0.
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?".
- add feature gate
- add basic tests
- adjust parser to eliminate conflict between `const fn` and associated
constants
- allow `const fn` in traits/trait-impls, but forbid later in type check
- correct some merge conflicts
For a trait *implementation* there are typedefs which are the types for
that particular trait and implementor. Skip these in the search index.
There were lots of dud items in the search index due to this (search for
Item, Iterator's associated type).
Add a boolean to clean::TypedefItem so that it tracks whether the it is
a type alias on its own, or if it's a `type` item in a trait impl.
Fixes#22442