| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit updates the bootstrap compiler, bumps the version to 1.23, updates
Cargo, updates books, and updates crates.io dependencies
|
|
|
|
|
|
|
|
This commit updates the bootstrap compiler and clears out a number
of #[cfg(stage0)] annotations and related business
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
This commit bumps the master branch's version to 1.21.0 and also updates the
bootstrap compiler from the freshly minted beta release.
|
|
support pub(restricted) in thread_local! (round 2)
Resurrected #40984 now that the issue blocking it was fixed. Original description:
`pub(restricted)` was stabilized in #40556 so let's go!
Here is a [playground](https://play.rust-lang.org/?gist=f55f32f164a6ed18c219fec8f8293b98&version=nightly&backtrace=1).
I changed the interface of `__thread_local_inner!`, which is supposedly unstable but this is not checked for macros (#34097 cc @petrochenkov @jseyfried), so this may be an issue.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Part of #29378 .
|
|
As of last year with version 'Sierra', the Mac operating system is now
called 'macOS'.
|
|
|
|
The versions show up in rustdoc.
|
|
Part of https://github.com/rust-lang/rust/issues/31869.
Also turn on the `missing_debug_implementations` lint at the crate
level.
|
|
|
|
Adds support for the x86_64-unknown-fuchsia target, which covers the
Fuchsia operating system.
|
|
|
|
|
|
|
|
Allows declaring multiple statics in one macro invocation, and supports attaching attributes to the generated items.
|
|
|
|
|
|
This test has been deadlocking and causing problems on the bots basically since
its inception. Some memory safety issues were fixed in 987dc84b, but the
deadlocks remained afterwards unfortunately.
After some investigation, I've concluded that this is just a situation where OSX
is not guaranteed to run destructors. The fix in 987dc84b observed that OSX was
rewriting the backing TLS memory to its initial state during destruction while
we weren't looking, and this would have the effect of canceling the destructors
of any other initialized TLS slots.
While very difficult to pin down, this is basically what I assume is happening
here, so there doesn't seem to really be anythig we can do to ensure the test
robustly passes on OSX, so just ignore it for now.
|
|
This transitions the standard library's `thread_local!` macro to use the
freshly-added and gated `#[cfg(target_thread_local)]` attribute. This greatly
simplifies the `#[cfg]` logic in play here, but requires that the standard
library expose both the OS and ELF TLS implementation modules as unstable
implementation details.
The implementation details were shuffled around a bit but end up generally
compiling to the same thing.
Closes #26581 (this supersedes the need for the option)
Closes #27057 (this also starts ignoring the option)
|
|
Due to #30228 it's not currently sound to do `*ptr = Some(value)`, so instead
use `mem::replace` which fixes the soundness hole for now.
|
|
|
|
|
|
|
|
* Lots of core prelude imports removed
* Makefile support for MSVC env vars and Rust crates removed
* Makefile support for morestack removed
|
|
This commit removes the injection of `std::env::args()` from `--test` expanded
code, relying on the test runner itself to call this funciton. This is more
hygienic because we can't assume that `std` exists at the top layer all the
time, and it meaks the injected test module entirely self contained.
|
|
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.
[rfc]: https://github.com/rust-lang/rfcs/pull/1184
|
|
This isn't actually necessary any more with the advent of `$crate` and changes
in the compiler to expand macros to `::core::$foo` in the context of a
`#![no_std]` crate.
The libcore inner module was also trimmed down a bit to the bare bones.
|
|
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.
The new lint is also a little more aggressive: specifically, it now
rejects tuples, and it recurses into function pointers.
|
|
TLS tests have been deadlocking on the OSX bots for quite some time now and this
commit is the result of the investigation into what's going on. It turns out
that a value in TLS which is being destroyed (e.g. the destructor is run) can be
reset back to the initial state **while the destructor is running** if TLS is
re-accessed.
To fix this we stop calling drop_in_place on OSX and instead move the data to a
temporary location on the stack.
|
|
|
|
|
|
|
|
|
|
This commit adds a ./configure option called `--disable-elf-tls` which disables
ELF based TLS (that which is communicated to LLVM) on platforms which already
support it. OSX 10.6 does not support this form of TLS, and some users of Rust
need to target 10.6 and are unable to do so due to the usage of TLS. The
standard library will continue to use ELF based TLS on OSX by default (as the
officially supported platform is 10.7+), but this adds an option to compile the
standard library in a way that is compatible with 10.6.
|
|
|
|
Fixes #25233
|
|
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
|
|
These commits build on [some great work on reddit](http://www.reddit.com/r/rust/comments/33boew/weekend_experiment_link_rust_programs_against/) for adding MUSL support to the compiler. This goal of this PR is to enable a `--target x86_64-unknown-linux-musl` argument to the compiler to work A-OK. The outcome here is that there are 0 compile-time dependencies for a MUSL-targeting build *except for a linker*. Currently this also assumes that MUSL is being used for statically linked binaries so there is no support for dynamically linked binaries with MUSL.
MUSL support largely just entailed munging around with the linker and where libs are located, and the major highlights are:
* The entirety of `libc.a` is included in `liblibc.rlib` (statically included as an archive).
* The entirety of `libunwind.a` is included in `libstd.rlib` (like with liblibc).
* The target specification for MUSL passes a number of ... flavorful options! Each option is documented in the relevant commit.
* The entire test suite currently passes with MUSL as a target, except for:
* Dynamic linking tests are all ignored as it's not supported with MUSL
* Stack overflow detection is not working MUSL yet (I'm not sure why)
* There is a language change included in this PR to add a `target_env` `#[cfg]` directive. This is used to conditionally build code for only MUSL (or for linux distros not MUSL). I highly suspect that this will also be used by Windows to target MSVC instead of a MinGW-based toolchain.
To build a compiler targeting MUSL you need to follow these steps:
1. Clone the current MUSL repo from `git://git.musl-libc.org/musl`. Build this as usual and install it.
2. Clone and build LLVM's [libcxxabi](http://libcxxabi.llvm.org/) library. Only the `libunwind.a` artifact is needed. I have tried using upstream libunwind's source repo but I have not gotten unwinding to work with it unfortunately. Move `libunwind.a` adjacent to MUSL's `libc.a`
3. Configure a Rust checkout with `--target=x86_64-unknown-linux-musl --musl-root=$MUSL_ROOT` where `MUSL_ROOT` is where you installed MUSL in step 1.
I hope to improve building a copy of libunwind as it's still a little sketchy and difficult to do today, but other than that everything should "just work"! This PR is not intended to include 100% comprehensive support for MUSL, as future modifications will probably be necessary.
|
|
Don't need so much manual #[doc(hidden)] and #[unstable] as much of it is
inherited!
|
