Still needs values of F_DUPFD_CLOEXEC on other OSs.
For Bitrig, NetBSD and OpenBSD the constant was incorrectly in posix01, when
it's actually posix08. In order to maintain backwards-compatiblity, the
constant was only copied, not moved.
cc #24237
Currently, `early_error` and `early_warn` in `librustc::session` always use `ColorConfig::Auto`. Modify them to follow the color configuration set by the `--color` option.
As colored output is also printed during the early stage, parsing the `--color` option should be done as early as possible. However, there are still some cases when the output needs to be colored before knowing the exact color settings. In these cases, it will be defaulted to `ColorConfig::Auto`, which is the same as before.
Fixes#27879.
For Bitrig, NetBSD and OpenBSD the constant was incorrectly in posix01, when
it's actually posix08, so we move it. This is a [breaking-change], but we
already had one in #27930.
Fix NetBSD's F_DUPFD_CLOEXEC constant.
For a similar feature detection, see this musl thread:
http://comments.gmane.org/gmane.linux.lib.musl.general/2963
This assumes that an int literal has type `c_int` for varidic functions.
It is very difficult to find tidy problems in the midst of the output of
the LLVM/jemalloc/etc. build, and travis is great for the former, so
lets remove that problem.
It is very difficult to find tidy problems in the midst of the output of
the LLVM/jemalloc/etc. build, and travis is great for the former, so
lets remove that problem.
Encountered an issue with `pacman` while going through the guide for installing the `mingw` toolchain on Windows with `msys2`, after some googling I found the [solution](https://github.com/Alexpux/MSYS2-packages/issues/163#issuecomment-73555971).
I thought it would be good to update the README so people don't get frustrated. 😃
r? @steveklabnik
After submitting #28031, I ran a [script](https://gist.github.com/durka/a5243440697c780f669b) on the rest of src/ and found some anomalies. In this PR are the fixes that I thought were obvious (but I might be wrong!). The others I've submitted in issue #28037.
If you have an `Iterator<Item=String>` (say because those items were generated using `.to_string()` or similarly), borrow semantics do not permit you map that to an `Iterator<&'a str>`. These two implementations close a small gap in the `String` API.
At the same time I've also made the names of the parameters to `String`'s `Extend` and `FromIterator` implementations consistent.
