Rollup of 9 pull requests #30544
Merged
Rollup of 9 pull requests #30544
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
steveklabnik
commented
Dec 23, 2015
steveklabnik
commented
- Successful merges: configure: test $SHELL's permission #30251, doc: minor format fixes in book/error-handling #30461, Made dynamic_lib migration path more explicit #30465, Small clarification in the rust book #30473, std: Remove old android header file #30529, doc: make line visible #30537, Minor fix to whitespace in libsyntax #30539, doc: Change Google link to generic top level domain #30541, Remove the FAQ and pare back the doc index #30543
- Failed merges:
This commit changes our distribution and in-tree sources to pass the `-C rpath` flag by default during compiles. This means that from-source builds, including our release channels, will have this option enabled as well. Motivated by rust-lang#29941, this change means that the compiler should be usable as-is on all platforms just after extraction or installation. This experience is already true on Windows but on Unixes you still need to set up LD_LIBRARY_PATH or the equivalent, which can often be unfortunate. This option was originally turned off by default for Linux distributions who tend to take care of these sorts of details themselves, so it is expected that all those builds of Rust will want to pass `--disable-rpath` to the configure script to preserve that behavior. Closes rust-lang#29941
Clarify the difference between compiler-panic and libcore-panic.
it isn't the good way to process, as it makes conflicts when building rustc while another version of rustc in installed system-wide.
By default, rustc use `cc` as linker. Under OpenBSD, `cc` is gcc version 4.2.1. So use the compiler found at configure-time for linking: it will be gcc 4.9. It permits to resolv problem of finding -lestdc++ or -lgcc. For base gcc (4.2), there are in not standard path, whereas for ports gcc (4.9) there are in standard path.
this PR reverts previous ones, that tried to make `cc` to found `estdc++` in `/usr/local/lib`. It causes more trouble than it resolvs things: rustc become unbuildable if another version already exists in `/usr/local` (for example, `libstd-xxxx.so` is found in `/usr/local/lib` and in builddir). so this PR tries another way to achieve build, but using the good linker for building. By default, rustc use `cc` for linking. But under OpenBSD, `cc` is gcc 4.2.1 from base, whereas we build with gcc 4.9 from ports. By linking using the compiler found at compile-time, we ensure that the compiler will found his own stdc++ library without trouble. r? @alexcrichton
Add note when item accessed from module via `m.i` rather than `m::i`. (I tried to make this somewhat future-proofed, in that the `UnresolvedNameContext` could be expanded in the future with other cases besides paths that are known to be modules.) This supersedes PR rust-lang#30356 ; since I'm responsible for a bunch of new code here, someone else should review it. :)
- upgrades libc to version with si_addr support in openbsd - declares libc use for getentropy
- upgrades libc to version with `si_addr` support in openbsd - declares libc use for getentropy - remove now unused use r? @alexcrichton
Lots of cruft to remove!
It's been awhile since we last updated jemalloc, and there's likely some bugs that have been fixed since the last version we're using, so let's try to update again.
…akis Lots of cruft to remove!
…richton It's been awhile since we last updated jemalloc, and there's likely some bugs that have been fixed since the last version we're using, so let's try to update again.
Checks for a `10.` prefix on the subfolder Signed-off-by: Peter Atashian <retep998@gmail.com>
…chton Checks for a `10.` prefix on the subfolder because that is what vcvars does. r? @alexcrichton
Currently the standard library has some pretty complicated logic to detect whether #[thread_local] should be used or whether it's supported. This is also unfortunately not quite true for OSX where not all versions support the #[thread_local] attribute (only 10.7+ does). Compiling code for OSX 10.6 is typically requested via the MACOSX_DEPLOYMENT_TARGET environment variable (e.g. the linker recognizes this), but the standard library unfortunately does not respect this. This commit updates the compiler to add a `target_thread_local` cfg annotation if the platform being targeted supports the `#[thread_local]` attribute. This is feature gated for now, and it is only true on non-aarch64 Linux and 10.7+ OSX (e.g. what the module already does today). Logic has also been added to parse the deployment target environment variable.
This change modifies the feature gating of special `#[cfg]` attributes to not require a `#![feature]` directive in the crate-of-use if the source of the macro was declared with `#[allow_internal_unstable]`. This enables the standard library's macro for `thread_local!` to make use of the `#[cfg(target_thread_local)]` attribute despite it being feature gated (e.g. it's a hidden implementation detail).
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 rust-lang#26581 (this supersedes the need for the option) Closes rust-lang#27057 (this also starts ignoring the option)
All these definitions can now be written in Rust, so do so!
All these definitions can now be written in Rust, so do so!
On some weird setup where $SHELL is a relative path (can happen under GNU Screen,) `file -L "$BIN_TO_PROBE"` fails and $CFG_CPUTYPE is wrongly set to i686. We should not only check its string value but also permission on filesystem.
…=alexcrichton Currently a compiler can be built with the `--disable-elf-tls` option for compatibility with OSX 10.6 which doesn't have ELF TLS. This is unfortunate, however, as a whole new compiler must be generated which can take some time. These commits add a new (feature gated) `cfg(target_thread_local)` annotation set by the compiler which indicates whether `#[thread_local]` is available for use. The compiler now interprets `MACOSX_DEPLOYMENT_TARGET` (a standard environment variable) to set this flag on OSX. With this we may want to start compiling our OSX nightlies with `MACOSX_DEPLOYMENT_TARGET` set to 10.6 which would allow the compiler out-of-the-box to generate 10.6-compatible binaries. For now the compiler still by default targets OSX 10.7 by allowing ELF TLS by default (e.g. if `MACOSX_DEPLOYMENT_TARGET` isn't set).
The corresopnding C file was removed in rust-lang#30175 and looks like I forgot to remove the header as well.
This commit changes our distribution and in-tree sources to pass the `-C rpath` flag by default during compiles. This means that from-source builds, including our release channels, will have this option enabled as well. Motivated by rust-lang#29941, this change means that the compiler should be usable as-is on all platforms just after extraction or installation. This experience is already true on Windows but on Unixes you still need to set up LD_LIBRARY_PATH or the equivalent, which can often be unfortunate. This option was originally turned off by default for Linux distributions who tend to take care of these sorts of details themselves, so it is expected that all those builds of Rust will want to pass `--disable-rpath` to the configure script to preserve that behavior. Closes rust-lang#29941
On some weird setup where $SHELL is a relative path (can happen under GNU Screen,) `file -L "$BIN_TO_PROBE"` fails and $CFG_CPUTYPE is wrongly set to i686. We should not only check its string value but also permission on filesystem.
The `dynamic_lib` library has been deprecated in favor of contents on crates.io, but apparently `libloading` is a more specific direction that fits the need.
Clarify the difference between compiler-panic and libcore-panic.
The corresopnding C file was removed in rust-lang#30175 and looks like I forgot to remove the header as well.
Country-code top level domain names are tied to a specific country (for example .de for Germany). r? @steveklabnik
The website will [shortly](rust-lang/prev.rust-lang.org#241) provide the main documentation landing page as well as the [FAQ](rust-lang/prev.rust-lang.org#202). All of the content here will be there. This strips out everything and makes the index *just* an index into the in-tree content. My only real qualm with this is that this will become the content on doc.rust-lang.org (a sweet URL), while the main documentation page will be www.rust-lang.org/documentation.html. r? @steveklabnik
|
@bors: r+ p=1 |
|
📌 Commit 944b337 has been approved by |
|
r? @Manishearth (rust_highfive has picked a reviewer for you, use r? to override) |
bors
added a commit
that referenced
this pull request
Dec 25, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.