The meaning of each variant of this enum was somewhat ambiguous and it's uncler
that we wouldn't even want to add more enumeration values in the future. As a
result this error has been altered to instead become an opaque structure.
Learning about the "first invalid byte index" is still an unstable feature, but
the type itself is now stable.
This commit series starts out with more official test harness support for rustdoc tests, and then each commit afterwards adds a test (where appropriate). Each commit should also test and finish independently of all others (they're all pretty separable).
I've uploaded a [copy of the documentation](http://people.mozilla.org/~acrichton/doc/std/) generated after all these commits were applied, and a double check on issues being closed would be greatly appreciated! I'll also browse the docs a bit and make sure nothing regressed too horribly.
The commit messages have more details as to what's going on, but this is a breaking change for any libraries which expect file descriptors to be inherited by default.
Closes#12148
The logic for only closing file descriptors >= 3 was inherited from quite some
time ago and ends up meaning that some internal APIs are less consistent than
they should be. By unconditionally closing everything entering a `FileDesc` we
ensure that we're consistent in our behavior as well as robustly handling the
stdio case.
The main change in this patch is removing the use of `Option` inside the
inner loops of those functions to avoid comparisons where one branch
will only trigger on the first pass through the loop.
The included benchmarks go from:
test bench_max ... bench: 372 ns/iter (+/- 118)
test bench_max_by ... bench: 428 ns/iter (+/- 33)
test bench_max_by2 ... bench: 7128 ns/iter (+/- 326)
to:
test bench_max ... bench: 317 ns/iter (+/- 64)
test bench_max_by ... bench: 356 ns/iter (+/- 270)
test bench_max_by2 ... bench: 1387 ns/iter (+/- 183)
Problem noticed in http://www.reddit.com/r/rust/comments/31syce/using_iterators_to_find_the_index_of_the_min_or/
The main change in this patch is removing the use of `Option` inside the
inner loops of those functions to avoid comparisons where one branch
will only trigger on the first pass through the loop.
The included benchmarks go from:
test bench_max ... bench: 372 ns/iter (+/- 118)
test bench_max_by ... bench: 428 ns/iter (+/- 33)
test bench_max_by2 ... bench: 7128 ns/iter (+/- 326)
to:
test bench_max ... bench: 317 ns/iter (+/- 64)
test bench_max_by ... bench: 356 ns/iter (+/- 270)
test bench_max_by2 ... bench: 1387 ns/iter (+/- 183)
Problem noticed in http://www.reddit.com/r/rust/comments/31syce/using_iterators_to_find_the_index_of_the_min_or/
* De-indent quite a bit by removing usage of FnOnce closures
* Clearly separate code for the parent/child after the fork
* Use `fs2::{File, OpenOptions}` instead of calling `open` manually
* Use RAII to close I/O objects wherever possible
* Remove loop for closing all file descriptors, all our own ones are now
`CLOEXEC` by default so they cannot be inherited
This commit starts to set the CLOEXEC flag for all files and sockets opened by
the standard library by default on all unix platforms. There are a few points of
note in this commit:
* The implementation is not 100% satisfactory in the face of threads. File
descriptors only have the `F_CLOEXEC` flag set *after* they are opened,
allowing for a fork/exec to happen in the middle and leak the descriptor.
Some platforms do support atomically opening a descriptor while setting the
`CLOEXEC` flag, and it is left as a future extension to bind these apis as it
is unclear how to do so nicely at this time.
* The implementation does not offer a method of opting into the old behavior of
not setting `CLOEXEC`. This will possibly be added in the future through
extensions on `OpenOptions`, for example.
* This change does not yet audit any Windows APIs to see if the handles are
inherited by default by accident.
This is a breaking change for users who call `fork` or `exec` outside of the
standard library itself and expect file descriptors to be inherted. All file
descriptors created by the standard library will no longer be inherited.
[breaking-change]
This is a really minor issue. I noticed some tests no longer need the ignore
tidy comment directive.
A quick grep turned up the following files:
src/test/compile-fail/bad-mid-path-type-params.rs
src/test/compile-fail/bad-sized.rs
src/test/compile-fail/coherence-default-trait-impl.rs
src/test/compile-fail/coherence-orphan.rs
src/test/compile-fail/issue-8767.rs
src/test/compile-fail/lint-stability.rs
src/test/compile-fail/lint-uppercase-variables.rs
src/test/compile-fail/typeck-default-trait-impl-outside-crate.rs
src/test/compile-fail/use-after-move-implicity-coerced-object.rs
src/test/debuginfo/gdb-pretty-std.rs
It didn't seem like it was worth opening an issue for this, but if that is not
the case (i.e. it is required), I'll open one up. Thanks!
This commit stabilizes the old `io::Error::from_os_error` after being renamed to
use the `raw_os_error` terminology instead. This function is often useful when
writing bindings to OS functions but only actually converting to an I/O error at
a later point.
This method hasn't really changed since is inception, and it can often be a
nice performance win for some situations. This method also imposes no burden on
implementors or users of `Clone` as it's just a default method on the side.
Now that we have a `#[allow_internal_unstable]` attribute for macros there's no
need for these two `begin_unwind` functions to be stable. Right now the `panic!`
interface is the only one we wish to stabilize, so remove the stability markers
from these functions.
While this is a breaking change, it is highly unlikely to break any actual code.
It is recommended to use the `panic!` macro instead if it breaks explicit calls
into `std::rt`.
[breaking-change]
cc #24208
r? @brson
I'm using this to integrate rustc with [american-fuzzy-lop](http://lcamtuf.coredump.cx/afl/). Building with afl instrumentation is no different from loading any other plugin library.
I'd like this PR to include a `run-make` test with a custom LLVM pass; however I'm not sure it's worth the trouble of building C++ code and linking LLVM from the test suite (are there existing tests that do this?)
Modify the ExprUseVisitor to walk each part of an AutoRef, and in
particular to treat an AutoUnsize as as kind of \"instantaneous\" borrow
of the value being unsized. This prevents us from feeding uninitialized
data.
This caused a problem for the eager reborrow of comparison traits,
because that wound up introducing a \"double AutoRef\", which was not
being thoroughly checked before but turned out not to type check.
Fortunately, we can just remove that \"eager reborrow\" as it is no longer
needed now that `PartialEq` doesn't force both LHS and RHS to have the
same type (and even if we did have this problem, the better way would be
to lean on introducing a common supertype).
Fixes#20791.
r? @nrc
This commit changes `Iterator`'s API by:
* Generalizing bounds from `Iterator` to `IntoIterator` whenever
possible, matching the semantics and ergonomics of `for` loops.
* Tightens up a few method-level bounds so that you get an error
earlier. For example, `rev` did not require `DoubleEndedIterator` even
though the result is only an `Iterator` when the original iterator was
double-ended.
Closes#23587
The bound-tightening is technically a:
[breaking-change]
but no code should break in practice.
The idea here is if you don't want rust in /usr/local
you can put something like this is your .profile:
```
export RUSTUP_PREFIX=$HOME/.local/rust
export PATH=$PATH:${RUSTUP_PREFIX}/bin
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:${RUSTUP_PREFIX}/lib
```
Then when you run rustup, it will update the install
in ${RUSTUP_PREFIX} without having to remember to pass
an explicit --prefix argument every time.
The idea here is if you don't want rust in /usr/local
you can put something like this is your .profile:
```
export RUSTUP_PREFIX=$HOME/.local/rust
export PATH=$PATH:${RUSTUP_PREFIX}/bin
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:${RUSTUP_PREFIX}/lib
```
Then when you run rustup, it will update the install
in ${RUSTUP_PREFIX} without having to remember to pass
an explicit --prefix argument every time.
We only implemented Clone on `extern "Rust" fn`s (for up to 8
parameters). This didn't cover `extern "C"` or `unsafe` (or
`unsafe extern "C"`) `fn`s, but there's no reason why they shouldn't be
cloneable as well.
The new impls are marked unstable because the existing impl for `extern
"Rust" fn`s is.
Fixes#24161.
This commit stabilizes the old `io::Error::from_os_error` after being renamed to
use the `raw_os_error` terminology instead. This function is often useful when
writing bindings to OS functions but only actually converting to an I/O error at
a later point.
This method hasn't really changed since is inception, and it can often be a
nice performance win for some situations. This method also imposes no burden on
implementors or users of `Clone` as it's just a default method on the side.
Now that we have a `#[allow_internal_unstable]` attribute for macros there's no
need for these two `begin_unwind` functions to be stable. Right now the `panic!`
interface is the only one we wish to stabilize, so remove the stability markers
from these functions.
While this is a breaking change, it is highly unlikely to break any actual code.
It is recommended to use the `panic!` macro instead if it breaks explicit calls
into `std::rt`.
[breaking-change]
cc #24208
