Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 10 pull requests #31882

Merged
merged 23 commits into from
Feb 25, 2016
Merged

Rollup of 10 pull requests #31882

merged 23 commits into from
Feb 25, 2016

Conversation

alexcrichton and others added 18 commits February 20, 2016 18:21
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
@Manishearth
Copy link
Member Author

@bors r+ p=20 force

@bors
Copy link
Contributor

bors commented Feb 25, 2016

📌 Commit df1076c has been approved by Manishearth

@Manishearth
Copy link
Member Author

@bors force

@Manishearth Manishearth reopened this Feb 25, 2016
@Manishearth
Copy link
Member Author

@bors force r+

@bors
Copy link
Contributor

bors commented Feb 25, 2016

📌 Commit df1076c has been approved by Manishearth

@bors
Copy link
Contributor

bors commented Feb 25, 2016

⌛ Testing commit df1076c with merge 35fc9d8...

@Manishearth
Copy link
Member Author

@bors r+

@bors
Copy link
Contributor

bors commented Feb 25, 2016

📌 Commit 10a2f15 has been approved by Manishearth

@bors
Copy link
Contributor

bors commented Feb 25, 2016

⌛ Testing commit 10a2f15 with merge b27e19c...

@bors
Copy link
Contributor

bors commented Feb 25, 2016

💔 Test failed - auto-linux-64-x-android-t

@Manishearth
Copy link
Member Author

@bors force r+

@bors
Copy link
Contributor

bors commented Feb 25, 2016

📌 Commit e584a49 has been approved by Manishearth

@Manishearth
Copy link
Member Author

@bors force

@bors
Copy link
Contributor

bors commented Feb 25, 2016

⌛ Testing commit e584a49 with merge c9852e2...

bors added a commit that referenced this pull request Feb 25, 2016
@bors
Copy link
Contributor

bors commented Feb 25, 2016

💔 Test failed - auto-linux-64-nopt-t

@Manishearth
Copy link
Member Author

@bors retry force

@bors
Copy link
Contributor

bors commented Feb 25, 2016

💔 Test failed - auto-linux-64-nopt-t

@alexcrichton
Copy link
Member

@bors: retry

On Thu, Feb 25, 2016 at 4:25 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/8171


Reply to this email directly or view it on GitHub
#31882 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants