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.
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!
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
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.
write_fmt calls write for each formatted field. The default implementation of write_fmt is used,
which will call write on not-yet-locked stdout (and write locking after), therefore making print!
in multithreaded environment still interleave contents of two separate prints.
I’m not sure whether we want to do this change, though, because it has the same deadlock hazard which we tried to avoid by not locking inside write_fmt itself (see [this comment](80def6c244/src/libstd/io/stdio.rs (L267))).
Spotted on [reddit].
cc @alexcrichton
[reddit]: http://www.reddit.com/r/rust/comments/31comh/println_with_multiple_threads/
write_fmt calls write for each formatted field. The default implementation of write_fmt is used,
which will call write on not-yet-locked stdout (and write locking after), therefore making print!
in multithreaded environment still interleave contents of two separate prints.
This patch implements reentrant mutexes, changes stdio handles to use these mutexes and overrides
write_fmt to lock the stdio handle for the whole duration of the call.
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).
Encode more precise scoping rules for function params
Function params outlive everything in the body (incl temporaries). Thus if we assign them their own `CodeExtent`, the region inference can properly show that it is sound to have temporaries with destructors that reference the parameters (because such temporaries will be dropped before the parameters are dropped).
Fix#23338
A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.
This commit reverts to the earlier behavior (while retaining the
refactoring into traits).
Fixes#24095Closes#24119
cc #24014
r? @alexcrichton
Addresses issue #22425. See `src/test/compile-fail/macro-incomplete-parse.rs` for a relevant test:
macro-incomplete-parse.rs:15:9: 15:10 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:15 , //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:27:1: 27:17 note: caused by the macro expansion here; the usage of `ignored_item` is likely invalid in this context
macro-incomplete-parse.rs:27 ignored_item!();
^~~~~~~~~~~~~~~~
macro-incomplete-parse.rs:20:14: 20:15 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:20 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:30:5: 30:21 note: caused by the macro expansion here; the usage of `ignored_expr` is likely invalid in this context
macro-incomplete-parse.rs:30 ignored_expr!();
^~~~~~~~~~~~~~~~
macro-incomplete-parse.rs:24:14: 24:15 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:24 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:32:9: 32:23 note: caused by the macro expansion here; the usage of `ignored_pat` is likely invalid in this context
macro-incomplete-parse.rs:32 ignored_pat!() => (),
^~~~~~~~~~~~~~
This does not address the case of improper expansion inside of an impl { } as seen in issue #21607.
I'm not sure if the note text is ideal, but it can be refined if needed.
The set of types which can have an inherent impl changed slightly and rustdoc
just needed to catch up to understand what it means to see a `impl str`!
Closes#23511
This ends up causing duplicate output in rustdoc. The source of these duplicates
is that the item is defined in both resolve namespaces, so it's listed twice.
Closes#23207
This change is aimed at improving cross-crate (inlined) notation of generic
closures. The change modifies `simplify::where_predicates` to handle
parenthesized notation as well as starting to handle supertrait bounds as well.
This was necessary because all output constraints of closures are bound to
`FnOnce` but most trait bounds are that of `FnMut`.
Close#21801
* All bounds are now discovered through the trait to be inlined.
* The `?Sized` bound now renders correctly for inlined associated types.
* All `QPath`s (`<A as B>::C`) instances are rendered as `A::C` where `C` is a
hyperlink to the trait `B`. This should improve at least how the docs look at
least.
* Supertrait bounds are now separated and display as the source lists them.
Closes#20727Closes#21145
Add a custom module to rustdoc which simplifies the output of `middle::ty` into
a more readable form which tends to be written down anyway!
Closes#20646
