- 10 4月, 2015 17 次提交
-
-
由 Alex Crichton 提交于
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.
-
由 Alex Crichton 提交于
* 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
-
由 Alex Crichton 提交于
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]
-
由 bors 提交于
None
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
Can anyone take a look? Very trivial.
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
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!
-
由 Manish Goregaokar 提交于
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.
-
由 Manish Goregaokar 提交于
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.
-
由 Manish Goregaokar 提交于
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
-
由 Manish Goregaokar 提交于
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?)
-
由 Manish Goregaokar 提交于
This makes the default configuration fully optimized, with no debugging options, no llvm asserts, renames --enable-debug to --enable-debug-assertions, and adds --enable-debug as a blanket option that toggles various things, per #17665. It does not add a `--enable-release` flag since that would be a no-op. cc @nrc Fixes https://github.com/rust-lang/rust/issues/22390 Fixes https://github.com/rust-lang/rust/issues/17081 Partially addresses https://github.com/rust-lang/rust/issues/17665
-
由 Manish Goregaokar 提交于
Closes #22289 Closes #22370 Closes #22384
-
由 Manish Goregaokar 提交于
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
-
- 09 4月, 2015 23 次提交
-
-
由 Aaron Turon 提交于
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.
-
由 bors 提交于
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
I'm not sure why this is failing. This patch disables this test until I can figure out what is wrong.
-
由 Manish Goregaokar 提交于
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.
-
由 Nick Cameron 提交于
-
由 bors 提交于
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.
-
由 Nick Cameron 提交于
-
由 bors 提交于
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.
-
由 Kevin Ballard 提交于
Seeking the `BufWriter` writes out its internal buffer before seeking.
-
由 Kevin Ballard 提交于
Seeking the `BufReader` discards the internal buffer (and adjusts the offset appropriately when seeking with `SeekFrom::Current(_)`).
-
由 Brian Anderson 提交于
libLTO fails to link here.
-
由 bors 提交于
Fix #13993. Fix #17167.
-
由 Alex Crichton 提交于
This commit removes pretty-expanded from all tests that wind up calling panic! one way or another now that its internals are unstable.
-
由 Alex Crichton 提交于
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.
-
由 Alex Crichton 提交于
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.
-
由 Alex Crichton 提交于
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
-
由 Luke Gallagher 提交于
-
由 Brian Anderson 提交于
-
由 bors 提交于
~~I believe this should fix the issue. Opening a PR to ensure noone duplicates effort, I'm running check now.~~ Closes #24091
-
由 Brian Anderson 提交于
-
由 Keegan McAllister 提交于
-
由 Brian Anderson 提交于
-