https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2020-07-28T00:51:13+00:00 2020-07-28T00:51:13+00:00 mark markm@cs.wisc.edu 2020-06-12T02:31:49+00:00 urn:sha1:2c31b45ae878b821975c4ebd94cc1e49f6073fd0 2020-07-15T16:57:05+00:00 Eric Huss eric@huss.org 2020-06-01T01:09:25+00:00 urn:sha1:6e9a1de0d146734e51cc7e761b288e9b9b138d4f 2020-07-12T09:46:42+00:00 Ralf Jung post@ralfj.de 2020-07-12T09:45:04+00:00 urn:sha1:7dc388654d6ef038065db23340e8eff7a567e5b4 2020-05-17T21:38:31+00:00 Ralf Jung post@ralfj.de 2020-05-17T17:37:44+00:00 urn:sha1:2764673dca6badb2ef89450bbdd84b19c317a9c7 2019-12-22T22:42:47+00:00 Mark Rousskov mark.simulacrum@gmail.com 2019-12-22T22:42:04+00:00 urn:sha1:a06baa56b95674fc626b3c3fd680d6a65357fe60 2019-08-28T15:34:31+00:00 Alex Crichton alex@alexcrichton.com 2019-07-23T14:25:34+00:00 urn:sha1:8fe65da935d7e01dbac897dcfbb4fb0f9f24e442 This commit removes the `wasm_syscall` feature from the wasm32-unknown-unknown build of the standard library. This feature was originally intended to allow an opt-in way to interact with the operating system in a posix-like way but it was never stabilized. Nowadays with the advent of the `wasm32-wasi` target that should entirely replace the intentions of the `wasm_syscall` feature. 2019-07-25T18:17:07+00:00 Alex Crichton alex@alexcrichton.com 2019-07-19T19:02:34+00:00 urn:sha1:dc50a633f3260a3aeb79a4ca9800587be7f732e7 This commit moves `thread_local!` on WebAssembly targets to using the `#[thread_local]` attribute in LLVM. This was recently implemented upstream and is [in the process of being documented][dox]. This change only takes affect if modules are compiled with `+atomics` which is currently unstable and a pretty esoteric method of compiling wasm artifacts. This "new power" of the wasm toolchain means that the old `wasm-bindgen-threads` feature of the standard library can be removed since it should now be possible to create a fully functioning threaded wasm module without intrusively dealing with libstd symbols or intrinsics. Yay! [dox]: https://github.com/WebAssembly/tool-conventions/pull/116 2019-06-10T17:58:44+00:00 Alex Crichton alex@alexcrichton.com 2019-06-10T15:12:14+00:00 urn:sha1:8eb7f36a3ba06dbea4a44254c3e2d92455ae150f 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-26T00:09:45+00:00 Alex Crichton alex@alexcrichton.com 2019-05-15T14:30:15+00:00 urn:sha1:d1040fe329a8db99ae0aae47975830a0829d7792 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-03-21T20:45:35+00:00 Jethro Beekman jethro@fortanix.com 2019-03-05T23:05:44+00:00 urn:sha1:2079df1c8740dd76d5c28bb8f6193826f6afdec4