about summary refs log tree commit diff
path: root/src/libstd/sys_common
AgeCommit message (Collapse)AuthorLines
2017-12-24Capture environment at spawnDiggory Blake-0/+145
2017-12-22fix some errors in libstdMichael Hewson-1/+1
2017-12-18Add lossless debug implementation for unix OsStrsDiggory Blake-0/+57
2017-12-13Move rust memchr impl to libcoreManish Goregaokar-228/+0
2017-12-11Merge remote-tracking branch 'origin/master' into miriOliver Schneider-8/+2
2017-12-09Use Try syntax for Option in place of macros or matchMatt Brubeck-8/+2
2017-12-06Update miri to rustc changesOliver Schneider-31/+131
2017-11-30rustc: Prepare to enable ThinLTO by defaultAlex Crichton-2/+20
This commit prepares to enable ThinLTO and multiple codegen units in release mode by default. We've still got a debuginfo bug or two to sort out before actually turning it on by default.
2017-11-25Implement `Rc`/`Arc` conversions for string-like typesMurarth-0/+14
Provides the following conversion implementations: * `From<`{`CString`,`&CStr`}`>` for {`Arc`,`Rc`}`<CStr>` * `From<`{`OsString`,`&OsStr`}`>` for {`Arc`,`Rc`}`<OsStr>` * `From<`{`PathBuf`,`&Path`}`>` for {`Arc`,`Rc`}`<Path>`
2017-11-19std: Add a new wasm32-unknown-unknown targetAlex Crichton-6/+11
This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
2017-11-09std: Avoid use of `libc` in portable modulesAlex Crichton-11/+11
This commit removes usage of the `libc` crate in "portable" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.
2017-10-10Rollup merge of #44775 - MaloJaffre:debug-struct, r=sfacklerkennytm-3/+10
Refactor to use `debug_struct` in several Debug impls Also use `pad` and derive `Debug` for `Edge`. Fixes #44771.
2017-10-09Refactor to use `debug_struct` in several Debug implsMalo Jaffré-3/+10
Fixes #44771.
2017-10-09Auto merge of #45041 - est31:master, r=alexcrichtonbors-2/+0
Remove support for the PNaCl target (le32-unknown-nacl) This removes support for the `le32-unknown-nacl` target which is currently supported by rustc on tier 3. Despite the "nacl" in the name, the target doesn't output native code (x86, ARM, MIPS), instead it outputs binaries in the PNaCl format. There are two reasons for the removal: * Google [has announced](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html) deprecation of the PNaCl format. The suggestion is to migrate to wasm. Happens we already have a wasm backend! * Our PNaCl LLVM backend is provided by the fastcomp patch set that the LLVM fork used by rustc contains in addition to vanilla LLVM (`src/llvm/lib/Target/JSBackend/NaCl`). Upstream LLVM doesn't have PNaCl support. Removing PNaCl support will enable us to move away from fastcomp (#44006) and have a lighter set of patches on top of upstream LLVM inside our LLVM fork. This will help distribution packagers of Rust. Fixes #42420
2017-10-05replace libc::res_init with res_init_if_glibc_before_2_26Jack O'Connor-4/+9
The previous workaround for gibc's res_init bug is not thread-safe on other implementations of libc, and it can cause crashes. Use a runtime check to make sure we only call res_init when we need to, which is also when it's safe. See https://github.com/rust-lang/rust/issues/43592.
2017-10-05Remove nacl from libstdest31-2/+0
2017-09-23docs improvement std::sync::{PoisonError, TryLockError}Lucas Morales-2/+55
2017-09-20Auto merge of #44525 - aidanhs:aphs-no-null-deref, r=alexcrichtonbors-15/+23
Correctly bubble up errors from libbacktrace Previously the first part of this code didn't check for a null pointer and blindly passed it back down, causing a segfault if libbacktrace failed to initialise. I've changed this to check and bubble up the error if relevant. Suggested diff view: https://github.com/rust-lang/rust/pull/44525/files?w=1
2017-09-17Add `<*const T>::align_offset` and use it in `memchr`Oliver Schneider-6/+3
2017-09-17Rollup merge of #44622 - frewsxcv:frewsxcv-invalid-link, r=QuietMisdreavusTim Neumann-1/+1
Fix incorrect `into_inner` link in docs. Fixes https://github.com/rust-lang/rust/issues/42373.
2017-09-15Fix incorrect `into_inner` link in docs.Corey Farwell-1/+1
Fixes https://github.com/rust-lang/rust/issues/42373.
2017-09-14Auto merge of #43972 - TobiasSchaffner:std_clean, r=alexcrichtonbors-22/+24
Add the libstd-modifications needed for the L4Re target This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re). A target for the L4Re was introduced in commit: c151220a84e40b65e45308cc0f3bbea4466d3acf In many aspects implementations for linux also apply for the L4Re microkernel. Some uncommon characteristics had to be resolved: * L4Re has no network funktionality * L4Re has a maximum stacksize of 1Mb for threads * L4Re has no uid or gid Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
2017-09-13Move default stack min size to thread implementationsTobias Schaffner-21/+18
The default min stack size value is smaller on l4re and therefore this value has to be different depending on the platform.
2017-09-12Correctly bubble up errors from libbacktraceAidan Hobson Sayers-15/+23
2017-09-08Move the stack size value for L4Re to the min_stack_size functionSebastian Humenda-0/+5
2017-09-08Re-enable networking module fo rL4ReSebastian Humenda-5/+5
As suggested in the discussion of PR #43972, std should provide a uniform API to all platforms. Since there's no networking on L4Re, this now is a module in `sys::net` providing types and functions/methods returning an error for each action.
2017-09-08Add modifications needed for L4re in libstdTobias Schaffner-1/+1
This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re). A target for the L4Re was introduced in commit: c151220a84e40b65e45308cc0f3bbea4466d3acf In many aspects implementations for linux also apply for the L4Re microkernel. Two uncommon characteristics had to be resolved: * L4Re has no network funktionality * L4Re has a maximum stacksize of 1Mb for threads Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
2017-09-02Add libbacktrace support for Apple platformsJohn Colanduoni-1/+1
2017-08-23Auto merge of #43830 - alexcrichton:path-display-regression, r=aturonbors-3/+7
std: Respect formatting flags for str-like OsStr Historically many `Display` and `Debug` implementations for `OsStr`-like abstractions have gone through `String::from_utf8_lossy`, but this was updated in #42613 to use an internal `Utf8Lossy` abstraction instead. This had the unfortunate side effect of causing a regression (#43765) in code which relied on these `fmt` trait implementations respecting the various formatting flags specified. This commit opportunistically adds back interpretation of formatting trait flags in the "common case" where where `OsStr`-like "thing" is all valid utf-8 and can delegate to the formatting implementation for `str`. This doesn't entirely solve the regression as non-utf8 paths will format differently than they did before still (in that they will not respect formatting flags), but this should solve the regression for all "real world" use cases of paths and such. The door's also still open for handling these flags in the future! Closes #43765
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-3/+3
Like #43008 (f668999), but _much more aggressive_.
2017-08-13std: Respect formatting flags for str-like OsStrAlex Crichton-3/+7
Historically many `Display` and `Debug` implementations for `OsStr`-like abstractions have gone through `String::from_utf8_lossy`, but this was updated in #42613 to use an internal `Utf8Lossy` abstraction instead. This had the unfortunate side effect of causing a regression (#43765) in code which relied on these `fmt` trait implementations respecting the various formatting flags specified. This commit opportunistically adds back interpretation of formatting trait flags in the "common case" where where `OsStr`-like "thing" is all valid utf-8 and can delegate to the formatting implementation for `str`. This doesn't entirely solve the regression as non-utf8 paths will format differently than they did before still (in that they will not respect formatting flags), but this should solve the regression for all "real world" use cases of paths and such. The door's also still open for handling these flags in the future! Closes #43765
2017-08-07addrinfo hint in lookup_host() needs clean initialization on all platformsDanek Duvall-10/+2
Fixes #43649
2017-07-13Fix backtrace on RedoxJeremy Soller-1/+2
2017-07-10Use LocalKey::try_with in stdLee Bousfield-8/+3
2017-07-06Implement TcpStream::connect_timeoutSteven Fackler-0/+8
This breaks the "single syscall rule", but it's really annoying to hand write and is pretty foundational.
2017-06-24Auto merge of #42687 - alexcrichton:windows-tls, r=sfacklerbors-1/+34
rustc: Enable #[thread_local] for Windows I think LLVM has had support for quite some time now for this, we just never got around to testing it out and binding it. We've had some trouble landing this in the past I believe, but it's time to try again! This commit flags the `#[thread_local]` attribute as being available for Windows targets and adds an implementation of `register_dtor` in the `thread::local` module to ensure we can destroy these keys. The same functionality is implemented in clang via a function called `__tlregdtor` (presumably provided in some Windows runtime somewhere), but this function unfortunately does not take a data pointer (just a thunk) which means we can't easily call it. For now destructors are just run in the same way the Linux fallback is implemented, which is just keeping track via a single OS-based TLS key.
2017-06-23rustc: Enable #[thread_local] for WindowsAlex Crichton-1/+34
I think LLVM has had support for quite some time now for this, we just never got around to testing it out and binding it. We've had some trouble landing this in the past I believe, but it's time to try again! This commit flags the `#[thread_local]` attribute as being available for Windows targets and adds an implementation of `register_dtor` in the `thread::local` module to ensure we can destroy these keys. The same functionality is implemented in clang via a function called `__tlregdtor` (presumably provided in some Windows runtime somewhere), but this function unfortunately does not take a data pointer (just a thunk) which means we can't easily call it. For now destructors are just run in the same way the Linux fallback is implemented, which is just keeping track via a single OS-based TLS key.
2017-06-23Removed as many "```ignore" as possible.kennytm-4/+4
Replaced by adding extra imports, adding hidden code (`# ...`), modifying examples to be runnable (sorry Homura), specifying non-Rust code, and converting to should_panic, no_run, or compile_fail. Remaining "```ignore"s received an explanation why they are being ignored.
2017-06-20Add `Read::initializer`.Steven Fackler-133/+0
This is an API that allows types to indicate that they can be passed buffers of uninitialized memory which can improve performance.
2017-06-15Avoid allocations in Debug for os_strStepan Koltsov-4/+42
Fixes #38879
2017-05-19Rollup merge of #41870 - excaliburHisSheath:iss29367-windows-docs, r=frewsxcvMark Simulacrum-0/+1
Improve docs in os::windows::ffi and os::windows::fs Part of #29367 This PR makes changes to the documentation in `os::windows::ffi` and `os::windows::fs` with the goal of fleshing them out and bringing them in line with Rust's quality standards. r? @steveklabnik
2017-05-09Don't show the std frames before user code on unwinding.Yamakaky-4/+40
When `RUST_BACKTRACE=1`, remove all frames after `__rust_maybe_catch_panic`. Tested on `main`, threads, tests and benches. Cleaning of the top of the stacktrace is let to a future PR. Fixes #40201 See #41815
2017-05-05Merge remote-tracking branch 'rust-lang/master' into iss29367-windows-docsDavid LeGare-85/+11
2017-05-05Update documention in windows::ffiDavid LeGare-0/+1
2017-05-05Rollup merge of #41582 - jonhoo:reread-nameservers-on-lookup-fail, ↵Corey Farwell-3/+16
r=alexcrichton Reload nameserver information on lookup failure As discussed in #41570, UNIX systems often cache the contents of `/etc/resolv.conf`, which can cause lookup failures to persist even after a network connection becomes available. This patch modifies lookup_host to force a reload of the nameserver entries following a lookup failure. This is in line with what many C programs already do (see #41570 for details). On systems with nscd, this should not be necessary, but not all systems run nscd. Fixes #41570. Depends on rust-lang/libc#585. r? @alexcrichton
2017-05-05std: Avoid locks during TLS destruction on WindowsAlex Crichton-15/+22
Gecko recently had a bug reported [1] with a deadlock in the Rust TLS implementation for Windows. TLS destructors are implemented in a sort of ad-hoc fashion on Windows as it doesn't natively support destructors for TLS keys. To work around this the runtime manages a list of TLS destructors and registers a hook to get run whenever a thread exits. When a thread exits it takes a look at the list and runs all destructors. Unfortunately it turns out that there's a lock which is held when our "at thread exit" callback is run. The callback then attempts to acquire a lock protecting the list of TLS destructors. Elsewhere in the codebase while we hold a lock over the TLS destructors we try to acquire the same lock held first before our special callback is run. And as a result, deadlock! This commit sidesteps the issue with a few small refactorings: * Removed support for destroying a TLS key on Windows. We don't actually ever exercise this as a public-facing API, and it's only used during `lazy_init` during racy situations. To handle that we just synchronize `lazy_init` globally on Windows so we never have to call `destroy`. * With no need to support removal the global synchronized `Vec` was tranformed to a lock-free linked list. With the removal of locks this means that iteration no long requires a lock and as such we won't run into the deadlock problem mentioned above. Note that it's still a general problem that you have to be extra super careful in TLS destructors. For example no code which runs a TLS destructor on Windows can call back into the Windows API to do a dynamic library lookup. Unfortunately I don't know of a great way around that, but this at least fixes the immediate problem that Gecko was seeing which is that with "well behaved" destructors the system would still deadlock! [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1358151
2017-05-04Reload nameserver information on lookup failureJon Gjengset-3/+16
As discussed in #41570, UNIX systems often cache the contents of /etc/resolv.conf, which can cause lookup failures to persist even after a network connection becomes available. This patch modifies lookup_host to force a reload of the nameserver entries following a lookup failure. This is in line with what many C programs already do (see #41570 for details). On systems with nscd, this should not be necessary, but not all systems run nscd. Introduces an std linkage dependency on libresolv on macOS/iOS (which also makes it necessary to update run-make/tools.mk). Fixes #41570. Depends on rust-lang/libc#585.
2017-04-18std: Back out backtrace pruning logicAlex Crichton-80/+4
It was discovered #40264 that this backtrace pruning logic is a little too aggressive, so while we figure how out to handle #40264 this commit backs out the changes to prune frames. Note that other cosmetic changes, such as better path printing and such remain.
2017-04-08Adding links around Sender/SyncSender/Receiver errors; Adding more ↵projektir-1/+3
documentation to channel() and sync_channel(); adding more links #29377
2017-03-30Replace hardcoded forward slash with path::MAIN_SEPARATORThomas Jespersen-2/+2
Fixes #40149