summary refs log tree commit diff
path: root/src/libstd/sys
AgeCommit message (Collapse)AuthorLines
2019-06-26Use pointer::write_bytes for android sigemptysetJosh Stone-5/+3
2019-06-26Avoid mem::uninitialized() in std::sys::unixJosh Stone-58/+57
For `libc` types that will be initialized in FFI calls, we can just use `MaybeUninit` and then pass around raw pointers. For `sun_path_offset()`, which really wants `offset_of`, all callers have a real `sockaddr_un` available, so we can use that reference.
2019-06-20Auto merge of #60341 - mtak-:macos-tlv-workaround, r=alexcrichtonbors-116/+1
macos tlv workaround fixes: #60141 Includes: * remove dead code: `requires_move_before_drop`. This hasn't been needed for a while now (oops I should have removed it in #57655) * redox had a copy of `fast::Key` (not sure why?). That has been removed. * Perform a `read_volatile` on OSX to reduce `tlv_get_addr` calls per `__getit` from (4-2 depending on context) to 1. `tlv_get_addr` is relatively expensive (~1.5ns on my machine). Previously, in contexts where `__getit` was inlined, 4 calls to `tlv_get_addr` were performed per lookup. For some reason when `__getit` is not inlined this is reduced to 2x - and performance improves to match. After this PR, I have only ever seen 1x call to `tlv_get_addr` per `__getit`, and macos now benefits from situations where `__getit` is inlined. I'm not sure if the `read_volatile(&&__KEY)` trick is working around an LLVM bug, or a rustc bug, or neither. r? @alexcrichton
2019-06-17Make use of `ptr::null(_mut)` instead of casting zeroLzu Tao-2/+2
2019-06-10std: Remove internal definitions of `cfg_if!` macroAlex Crichton-5/+5
This is duplicated in a few locations throughout the sysroot to work around issues with not exporting a macro in libstd but still wanting it available to sysroot crates to define blocks. Nowadays though we can simply depend on the `cfg-if` crate on crates.io, allowing us to use it from there!
2019-05-29Rollup merge of #61202 - oberien:permissionext-print-octal, r=varkorMazdak Farrokhzad-2/+2
Print PermissionExt::mode() in octal in Documentation Examples Printing the file permission mode on unix systems in decimal feels unintuitive. Printing it in octal gives the expected form of e.g. `664`.
2019-05-26Print file mode of PermissionExt in octal in Examplesoberien-2/+2
2019-05-25std: Depend on `backtrace` crate from crates.ioAlex Crichton-1794/+0
This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics, but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another, but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general, and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature, however, uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary, so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well, but I figured I'd hold off on that until we get closer to merging.
2019-05-22Revert "Add implementations of last in terms of next_back on a bunch of ↵Steven Fackler-8/+0
DoubleEndedIterators." This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
2019-05-22Rollup merge of #60581 - hellow554:fix_60580, r=alexcrichtonMazdak Farrokhzad-57/+46
convert custom try macro to `?` resolves #60580 r? @frewsxcv
2019-05-20Rollup merge of #60453 - tbu-:pr_getrandom_enoperm, r=sfacklerMazdak Farrokhzad-1/+6
Fall back to `/dev/urandom` on `EPERM` for `getrandom` This can happen because of seccomp or some VMs. Fixes #52609.
2019-05-15restructure thread_local! for better codegen (especially on macos)tyler-1/+1
2019-05-15Revert "ensure fast thread local lookups occur once per access on macos"tyler-26/+1
This reverts commit d252f3b77f3b7d4cd59620588f9d026633c05816.
2019-05-15ensure fast thread local lookups occur once per access on macostyler-1/+26
2019-05-15redox had a copy of fast thread local (oversight?)tyler-104/+1
2019-05-15remove dead code: requires_move_before_droptyler-12/+0
2019-05-15Auto merge of #60775 - hellow554:no_bitrig, r=joshtriplettbors-35/+9
Remove bitrig support from rust Resolves #60743 using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?). There's also this file https://github.com/rust-lang/rls/blob/5b8e99bb61958ca8abcb7c5eda70521726be1065/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
2019-05-14Rollup merge of #60780 - RalfJung:miri, r=oli-obkMazdak Farrokhzad-4/+1
fix Miri This reverts https://github.com/rust-lang/rust/pull/60156, which turned out to be a dead end (see https://github.com/rust-lang/rust/pull/60469). r? @oli-obk
2019-05-14Rollup merge of #60130 - khuey:efficient_last, r=sfacklerMazdak Farrokhzad-0/+8
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators. I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so. The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
2019-05-13Revert "use SecRandomCopyBytes on macOS in Miri"Ralf Jung-4/+1
This reverts commit 54aefc6a2d076b74921a8d78c5d8c68c13bfa4a7.
2019-05-13Remove bitrig support from rustMarcel Hellwig-35/+9
2019-05-06use exhaustive_patterns to be able to use `?`Marcel Hellwig-12/+15
2019-05-06convert custom try macro to `?`Marcel Hellwig-45/+31
resolves #60580
2019-05-03Categorize WASI as an "OS" rather than as an "environment".Dan Gohman-1/+1
This distinction is fairly abstract, but in practice, the main advantage here is that LLVM's triple code considers WASI to be an OS, so this makes rustc agree with that.
2019-05-03Auto merge of #60496 - jethrogb:jb/address-integer-overflow, r=alexcrichtonbors-7/+17
Fix potential integer overflow in SGX memory range calculation. Thanks to Eduard Marin and David Oswald at the University of Burmingham, and Jo Van Bulck at KU Leuven for discovering this issue.
2019-05-03Rollup merge of #60373 - rasendubi:lang-features-sort-since, r=CentrilMazdak Farrokhzad-41/+41
Tidy: ensure lang features are sorted by since This is the tidy side of https://github.com/rust-lang/rust/issues/60361. What is left is actually splitting features into groups and sorting by since. This PR also likely to produce a small (a couple of lines) merge conflict with https://github.com/rust-lang/rust/pull/60362. r? @Centril
2019-05-03Auto merge of #59883 - ebarnard:clonefile, r=sfacklerbors-19/+69
Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS The behaviour of MacOS now matches Linux which uses `copy_file_range` to perform CoW file copies where available and supported by the underlying filesystem.
2019-05-02Fix potential integer overflow in SGX memory range calculation.Jethro Beekman-7/+17
Thanks to Eduard Marin and David Oswald at the University of Burmingham, and Jo Van Bulck at KU Leuven for discovering this issue.
2019-05-02Make tidy::version::Version a [u32; 3]Alexey Shmalko-41/+41
2019-05-02Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS.Edward Barnard-19/+69
2019-05-02Auto merge of #60156 - RalfJung:macos-rand, r=oli-obk,alexcrichtonbors-1/+4
use SecRandomCopyBytes on macOS in Miri This is a hack to fix https://github.com/rust-lang/miri/issues/686: on macOS, rustc will open `/dev/urandom` to initialize a `HashMap`. That's quite hard to emulate properly in Miri without a full-blown implementation of file descriptors. However, Miri needs an implementation of `SecRandomCopyBytes` anyway to support [getrandom](https://crates.io/crates/getrandom), so using it here should work just as well. This will only have an effect when libstd is compiled specifically for Miri, but that will generally be the case when people use `cargo miri`. This is clearly a hack, so I am opening this to start a discussion about whether we are okay with such a hack or not. Cc @oli-obk
2019-05-01Fall back to `/dev/urandom` on `EPERM` for `getrandom`Tobias Bucher-1/+6
This can happen because of seccomp or some VMs. Fixes #52609.
2019-04-29SGX target: implemented vectored I/OJethro Beekman-13/+50
2019-04-29SGX target: don't unwind on usercall index out of boundsJethro Beekman-2/+10
2019-04-27Stabilized vectored IOSteven Fackler-169/+169
This renames `std::io::IoVec` to `std::io::IoSlice` and `std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes `std::io::IoSlice`, `std::io::IoSliceMut`, `std::io::Read::read_vectored`, and `std::io::Write::write_vectored`. Closes #58452
2019-04-21use SecRandomCopyBytes on macOS in MiriRalf Jung-1/+4
2019-04-19Add implementations of last in terms of next_back on a bunch of ↵Kyle Huey-0/+8
DoubleEndedIterators. r?Manishearth
2019-04-19Fix sync_all on macos/iosDavid Vázquez Púa-2/+9
sync_all should flush all metadata in macos/ios, so it should call fcntl with the F_FULLFSYNC flag as sync_data does. Fixes #55920
2019-04-16SGX target: change re-entry abort logicJethro Beekman-19/+11
2019-04-16Add a comment explaining why SecRandomCopyBytes is not used on MacOSEd Barnard-0/+7
2019-04-14Rollup merge of #59852 - alexcrichton:more-vectored, r=sfacklerMazdak Farrokhzad-34/+163
std: Add `{read,write}_vectored` for more types This commit implements the `{read,write}_vectored` methods on more types in the standard library, namely: * `std::fs::File` * `std::process::ChildStd{in,out,err}` * `std::io::Std{in,out,err}` * `std::io::Std{in,out,err}Lock` * `std::io::Std{in,out,err}Raw` Where supported the OS implementations hook up to native support, otherwise it falls back to the already-defaulted implementation.
2019-04-14Rollup merge of #59818 - crlf0710:eliminate_libstd_fnbox, r=cramertjMazdak Farrokhzad-17/+9
Eliminate `FnBox` usages from libstd.
2019-04-12Rollup merge of #59892 - rylev:as-raw-fd, r=alexcrichtonMazdak Farrokhzad-67/+190
Impl RawFd conversion traits for WASI TcpListener, TcpStream and UdpSocket r? @alexcrichton
2019-04-11Impl RawFd converstion traits for TcpListener, TcpStream and UdpSocketRyan Levick-67/+190
2019-04-10SGX target: fix cfg(test) buildJethro Beekman-3/+3
2019-04-10std: Add `{read,write}_vectored` for more typesAlex Crichton-34/+163
This commit implements the `{read,write}_vectored` methods on more types in the standard library, namely: * `std::fs::File` * `std::process::ChildStd{in,out,err}` * `std::io::Std{in,out,err}` * `std::io::Std{in,out,err}Lock` * `std::io::Std{in,out,err}Raw` Where supported the OS implementations hook up to native support, otherwise it falls back to the already-defaulted implementation.
2019-04-10Eliminate `FnBox` usages from libstd.CrLF0710-17/+9
2019-04-06Rollup merge of #59727 - alexcrichton:wasi-apis, r=fitzgenMazdak Farrokhzad-87/+86
wasi: Use shared API for preopened fds This commit updates the wasi target with supported added in CraneStation/wasi-sysroot#10. That function allows both C and Rust to cooperate in how preopened files are managed, enabling us to learn about propened files through the same interface. The `open_parent` function in the wasi `fs` module was updated to avoid its own initialization of a global preopened map and instead delegate to libc to perform this functionality. This should both be more robust into the future in terms of handling path logic as well as ensuring the propened map is correctly set up at process boot time. This does currently require some unfortunate allocations on our side, but if that becomes an issue we can always paper over those in time!
2019-04-06Rollup merge of #59624 - jethrogb:jb/sgx-unwind-syms, r=alexcrichtonMazdak Farrokhzad-41/+44
SGX target: Use linker option to avoid code CGU assignment kludge cc @VardhanThigle @faern
2019-04-05wasi: Use shared API for preopened fdsAlex Crichton-87/+86
This commit updates the wasi target with supported added in CraneStation/wasi-sysroot#10. That function allows both C and Rust to cooperate in how preopened files are managed, enabling us to learn about propened files through the same interface. The `open_parent` function in the wasi `fs` module was updated to avoid its own initialization of a global preopened map and instead delegate to libc to perform this functionality. This should both be more robust into the future in terms of handling path logic as well as ensuring the propened map is correctly set up at process boot time. This does currently require some unfortunate allocations on our side, but if that becomes an issue we can always paper over those in time!
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-14 10:00:19 +0000