Skip to content

Rollup of 10 pull requests #31882

New issue

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

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

Already on GitHub? # to your account

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
Collaborator

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
Collaborator

bors commented Feb 25, 2016

📌 Commit df1076c has been approved by Manishearth

@bors
Copy link
Collaborator

bors commented Feb 25, 2016

⌛ Testing commit df1076c with merge 35fc9d8...

@Manishearth
Copy link
Member Author

@bors r+

@bors
Copy link
Collaborator

bors commented Feb 25, 2016

📌 Commit 10a2f15 has been approved by Manishearth

@bors
Copy link
Collaborator

bors commented Feb 25, 2016

⌛ Testing commit 10a2f15 with merge b27e19c...

@bors
Copy link
Collaborator

bors commented Feb 25, 2016

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

@Manishearth
Copy link
Member Author

@bors force r+

@bors
Copy link
Collaborator

bors commented Feb 25, 2016

📌 Commit e584a49 has been approved by Manishearth

@Manishearth
Copy link
Member Author

@bors force

@bors
Copy link
Collaborator

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
Collaborator

bors commented Feb 25, 2016

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

@Manishearth
Copy link
Member Author

@bors retry force

@bors
Copy link
Collaborator

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).

# for free to join this conversation on GitHub. Already have an account? # 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