Rollup of 10 pull requests #31882
Rollup of 10 pull requests #31882
Conversation
Manishearth
commented
Feb 25, 2016
Manishearth
commented
- Successful merges: resolve: fix the visibility of extern crates #31362, rustc: Refactor how unstable flags are handled #31793, mk: Specify armv6 for gcc on arm-unknown-linux-* #31800, Environment variable iterator overrides #31809, Add crate_name in E0152 error display #31818, Fix warn(unused_mut) in example #31827, Correct char.encode_utf16() documentation #31831, rustdoc: Fix source-links for files with absolute-paths #31835, rustdoc: Don't record associated items from trait impls in the search-index #31837, mk: Move disable-jemalloc logic into makefiles #31846
- Failed merges:
Right now the compiler's we're using actually default to armv7/thumb2 I believe, so this should help push them back to what the arm-unknown-linux-* targets are for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf` target which is to map it to an armv6 architecture. Closes rust-lang#31787
The "A buffer that's too small" example was calling encode_utf8().
`clean_srcpath` tries to make the source-path relative to `src_root`, but this didn't work since `src_root` itself wasn't absolute.
This commit adds support for *truly* unstable options in the compiler, as well as adding warnings for the start of the deprecation path of unstable-but-not-really options. Specifically, the following behavior is now in place for handling unstable options: * As before, an unconditional error is emitted if an unstable option is passed and the `-Z unstable-options` flag is not present. Note that passing another `-Z` flag does not require passing `-Z unstable-options` as well. * New flags added to the compiler will be in the `Unstable` category as opposed to the `UnstableButNotReally` category which means they will unconditionally emit an error when used on stable. * All current flags are in a category where they will emit warnings when used that the option will soon be a hard error. Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate where it is required to unlock unstable functionality. A nightly compiler which is used without any `-Z` flags should only be exercising stable behavior.
…ty, r=nikomatsakis This PR changes the visibility of extern crate declarations to match that of items (fixes rust-lang#26775). To avoid breakage, the PR makes it a `public_in_private` lint to reexport a private extern crate, and it adds the lint `inaccessible_extern_crate` for uses of an inaccessible extern crate. The lints can be avoided by making the appropriate `extern crate` declaration public.
…, r=nikomatsakis This commit adds support for *truly* unstable options in the compiler, as well as adding warnings for the start of the deprecation path of unstable-but-not-really options. Specifically, the following behavior is now in place for handling unstable options: * As before, an unconditional error is emitted if an unstable option is passed and the `-Z unstable-options` flag is not present. Note that passing another `-Z` flag does not require passing `-Z unstable-options` as well. * New flags added to the compiler will be in the `Unstable` category as opposed to the `UnstableButNotReally` category which means they will unconditionally emit an error when used on stable. * All current flags are in a category where they will emit warnings when used that the option will soon be a hard error. Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate where it is required to unlock unstable functionality. A nightly compiler which is used without any `-Z` flags should only be exercising stable behavior.
Right now the compiler's we're using actually default to armv7/thumb2 I believe, so this should help push them back to what the arm-unknown-linux-* targets are for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf` target which is to map it to an armv6 architecture. Closes rust-lang#31787
|
@bors r+ p=20 force |
|
📌 Commit df1076c has been approved by |
|
@bors force |
|
@bors force r+ |
|
📌 Commit df1076c has been approved by |
|
⌛ Testing commit df1076c with merge 35fc9d8... |
|
@bors r+ |
|
📌 Commit 10a2f15 has been approved by |
|
⌛ Testing commit 10a2f15 with merge b27e19c... |
|
💔 Test failed - auto-linux-64-x-android-t |
The "A buffer that's too small" example was calling encode_utf**8**().
…ichton This effectively only records associated items from either inherent impls or trait definitions in the search-index. fixes rust-lang#31808 r? @alexcrichton
|
@bors force r+ |
|
📌 Commit e584a49 has been approved by |
|
@bors force |
|
💔 Test failed - auto-linux-64-nopt-t |
|
@bors retry force |
|
⚡ Previous build results for auto-linux-32-nopt-t, auto-linux-64-opt, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-64-nopt-t, auto-mac-ios-opt are reusable. Rebuilding only auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt... |
|
💔 Test failed - auto-linux-64-nopt-t |
|
@bors: retry On Thu, Feb 25, 2016 at 4:25 AM, bors notifications@github.com wrote:
|
|
⚡ Previous build results for auto-linux-32-nopt-t, auto-linux-64-opt, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-64-nopt-t, auto-mac-ios-opt are reusable. Rebuilding only auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt... |
