This isn't actually necessary any more with the advent of `$crate` and changes
in the compiler to expand macros to `::core::$foo` in the context of a
`#![no_std]` crate.
The libcore inner module was also trimmed down a bit to the bare bones.
As there’s no C++ runtime any more there’s really no point in having
anything but Rust tags being made.
I’ve also taken the liberty of excluding the compiler parts of this in
the `librust%,,` pattern substitution. Whether or not this is “correct”
will depend on whether you want tags for the compiler or for general
use. For myself, I want it for general use.
I’m not sure how much people use the tags files anyway. I definitely do,
but with Racer existing the tags files aren’t quite so necessary.
The API we're calling requires us to pass an absolute point in time as an
argument (`pthread_cond_timedwait`) so we call `gettimeofday` ahead of time to
then add the specified duration to. Unfortuantely the current "add the duration"
logic forgot to take into account the current time's sub-second precision (e.g.
the `tv_usec` field was ignored), causing sub-second duration waits to return
spuriously.
Added definitions for 'Expression', 'Expression-Oriented Language' and 'Statement' to glossary.
Sorted the definitions alphabetically.
r? @steveklabnik
These methods are all covered by [RFC 1158] and are currently all available on
stable Rust via the [`net2` crate][net2] on crates.io. This commit does not
touch the timeout related functions as they're still waiting on `Duration` which
is unstable anyway, so punting in favor of the `net2` crate wouldn't buy much.
[RFC 1158]: https://github.com/rust-lang/rfcs/pull/1158
[net2]: http://crates.io/crates/net2
The API we're calling requires us to pass an absolute point in time as an
argument (`pthread_cond_timedwait`) so we call `gettimeofday` ahead of time to
then add the specified duration to. Unfortuantely the current "add the duration"
logic forgot to take into account the current time's sub-second precision (e.g.
the `tv_usec` field was ignored), causing sub-second duration waits to return
spuriously.
Closure variables represent the closure environment, not the closure
function, so the identifier used to ensure that the debuginfo is unique
for each kind of closure needs to be based on the closure upvars and not
the function signature.
As described in the module documentation, the memory orderings in Rust
are the same with that of LLVM. However, the documentation for the
memory orderings enum says the memory orderings are the same of that of
C++. Note that they differ in that C++'s support the consume reads,
while LLVM's does not. Hence this commit fixes the bug in the
documentation for the enum.
Noticed that syntax like `vec![0; 5]` is never mentioned in `Vec<T>`'s docs, nor used in any of its methods' docs, so I figured I should add a mention of it. Also noticed `vec!(1, 2)` being used in one spot while I was at it, so I fixed that as well for consistency's sake.
r? @steveklabnik
The first paragraph of the docs of the Cursor struct ([src](ff6c6ce917/src/libstd/io/cursor.rs (L18-L21))) contains a Markdown link. In listings (like <http://doc.rust-lang.org/nightly/std/io/>), this won't get rendered:
The hotfix would be to change the link by reference:
```rust
/// A `Cursor` wraps another type and provides it with a [`Seek`][seek]
/// implementation.
///
/// [seek]: trait.Seek.html
```
to a direct link:
```rust
/// A `Cursor` wraps another type and provides it with a
/// [`Seek`](trait.Seek.html) implementation.
```
_I have not tested this as I don't have access to a machine for compiling Rust right now._
(This seems to be a more general issue, but I think I have seen this mentioned before. This PR is just to hotfix on particular occurrence. Rustdoc seems to only read the first paragraph of a doc string for the description in index pages, and _after that_ convert Markdown to HTML.)
r? @steveklabnik
Improves diagnostics in various locations, namely:
* A few error messages that orignally were a mix of an error message and suggestion how to fix it have been split up into two messages: an error and help/hint.
* Never report “illegal”. Fixes https://github.com/rust-lang/rust/issues/27288
The reader could probably infer this from the current text, but for C++ programmers it's not obvious that struct fields don't automatically become public.
Apparently I wasn't the only one to be confused:
http://stackoverflow.com/questions/29157300/field-of-struct-is-private-when-importing-module
I don't think an example is necessary, but can add one if desired.
r? @steveklabnik
As described in the module documentation, the memory orderings in Rust
are the same with that of LLVM. However, the documentation for the
memory orderings enum says the memory orderings are the same of that of
C++. Note that they differ in that C++'s support the consume reads,
while LLVM's does not. Hence this commit fixes the bug in the
documentation for the enum.
These aren't really used for anything any more, so there doesn't seem to be much
reason to leave them around in the `rt` directory. There was some limiting of
threads spawned or tests when run under valgrind, but very little is run under
valgrind nowadays so there's also no real use keeping these around.
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
[rfc]: https://github.com/rust-lang/rfcs/pull/1193Closes#27259
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
[rfc]: https://github.com/rust-lang/rfcs/pull/1193Closes#27259
`EmitterWriter::print_maybe_styled` was basically always used with `format!`, so this macro makes some code cleaner. It should also remove some unnecessary allocations (most `print_maybe_styled` invocations allocated a `String` previously, whereas the new macro uses `write_fmt` to write the formatted string directly to the terminal).
This probably could have been part of #26838, but it’s too late now. It’s also rebased on #26838’s branch because otherwise pretty much all of the changes in this PR would conflict with the other PR’s changes.
The following APIs were all marked with a `#[stable]` tag:
* process::Child::id
* error::Error::is
* error::Error::downcast
* error::Error::downcast_ref
* error::Error::downcast_mut
* io::Error::get_ref
* io::Error::get_mut
* io::Error::into_inner
* hash::Hash::hash_slice
* hash::Hasher::write_{i,u}{8,16,32,64,size}
