-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 14 pull requests #52268
Merged
Merged
Rollup of 14 pull requests #52268
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
this gives us some leeway when optimizing
…ned behavior could arise Inspired by @gnzlbg at rust-lang#46043 (comment)
- [std: Rewrite the `sync` modulehttps://github.com/rust-lang/rust/commit/71d4e77db8ad4b6d821da7e5d5300134ac95974e) (Nov 2014) ```diff - pub fn doit(&self, f: ||) { + pub fn doit(&'static self, f: ||) { ``` > ```text > The second layer is the layer provided by `std::sync` which is intended to be > the thinnest possible layer on top of `sys_common` which is entirely safe to > use. There are a few concerns which need to be addressed when making these > system primitives safe: > > * Once used, the OS primitives can never be **moved**. This means that they > essentially need to have a stable address. The static primitives use > `&'static self` to enforce this, and the non-static primitives all use a > `Box` to provide this guarantee. > ``` The author of this diff is @alexcrichton. `sync::Once` contains only a pointer to (privately hidden) `Waiter`s, which are all stack-allocated. The `'static` bound to `sync::Once` is thus unnecessary to guarantee that any OS primitives are non-relocatable. See https://internals.rust-lang.org/t/sync-once-per-instance/7918 for more context.
Correct suggestion for println Closes rust-lang#51585 r? @estebank
hygiene: Decouple transparencies from expansion IDs And remove fallback to parent modules during resolution of names in scope. This is a breaking change for users of unstable macros 2.0 (both procedural and declarative), code like this: ```rust #![feature(decl_macro)] macro m($S: ident) { struct $S; mod m { type A = $S; } } fn main() { m!(S); } ``` or equivalent ```rust #![feature(decl_macro)] macro m($S: ident) { mod m { type A = $S; } } fn main() { struct S; m!(S); } ``` stops working due to module boundaries being properly enforced. For proc macro derives this is still reported as a compatibility warning to give `actix_derive`, `diesel_derives` and `palette_derive` time to fix their issues. Fixes rust-lang#50504 in accordance with [this comment](rust-lang#50504 (comment)).
…hton step_by: leave time of item skip unspecified This gives us some leeway when optimizing. `StepBy<RangeFrom<_>>` is one case where this is needed.
improve error message shown for unsafe operations Add a short explanation saying why undefined behavior could arise. In particular, the error many people got for "creating a pointer to a packed field requires unsafe block" was not worded great -- it lead to people just adding the unsafe block without considering if what they are doing follows the rules. I am not sure if a "note" is the right thing, but that was the easiest thing to add... Inspired by @gnzlbg at rust-lang#46043 (comment)
Deny bare trait objects in in src/liballoc Enforce #![deny(bare_trait_objects)] in src/liballoc.
Deny bare trait objects in in src/libsyntax Enforce `#![deny(bare_trait_objects)]` in `src/libsyntax`.
Remove sync::Once::call_once 'static bound See https://internals.rust-lang.org/t/sync-once-per-instance/7918 for more context. Suggested r is @alexcrichton, the one who added the `'static` bound back in 2014. I don't want to officially r? though, if the system would even let me. I'd rather let the system choose the appropriate member since it knows more than I do. `git blame` history for `sync::Once::call_once`'s signature: - [std: Second pass stabilization of sync](rust-lang@f3a7ec7) (Dec 2014) ```diff - pub fn doit<F>(&'static self, f: F) where F: FnOnce() { + #[stable] + pub fn call_once<F>(&'static self, f: F) where F: FnOnce() { ``` - [libstd: use unboxed closures](rust-lang@cdbb3ca) (Dec 2014) ```diff - pub fn doit(&'static self, f: ||) { + pub fn doit<F>(&'static self, f: F) where F: FnOnce() { ``` - [std: Rewrite the `sync` module](rust-lang@71d4e77) (Nov 2014) ```diff - pub fn doit(&self, f: ||) { + pub fn doit(&'static self, f: ||) { ``` > ```text > The second layer is the layer provided by `std::sync` which is intended to be > the thinnest possible layer on top of `sys_common` which is entirely safe to > use. There are a few concerns which need to be addressed when making these > system primitives safe: > > * Once used, the OS primitives can never be **moved**. This means that they > essentially need to have a stable address. The static primitives use > `&'static self` to enforce this, and the non-static primitives all use a > `Box` to provide this guarantee. > ``` The author of this diff is @alexcrichton. `sync::Once` now contains only a pointer to (privately hidden) `Waiter`s, which are all stack-allocated. The `'static` bound to `sync::Once` is thus unnecessary to guarantee that any OS primitives are non-relocatable. As the `'static` bound is not required for `sync::Once`'s operation, removing it is strictly more useful. As an example, it allows attaching a one-time operation to instances rather than only to global singletons.
Deny bare trait objects in in src/librustc Enforce `#![deny(bare_trait_objects)]` in `src/librustc`.
…i-obk Deny bare trait objects in in src/librustc_allocator Enforce `#![deny(bare_trait_objects)]` in `src/librustc_allocator`.
…=varkor Deny bare trait objects in in src/librustc_codegen_llvm Enforce `#![deny(bare_trait_objects)]` in `src/librustc_codegen_llvm`.
…, r=cramertj Deny bare trait objects in in src/librustc_data_structures Enforce `#![deny(bare_trait_objects)]` in `src/librustc_data_structures`.
…mertj Deny bare trait objects in in src/librustc_metadata Enforce `#![deny(bare_trait_objects)]` in `src/librustc_metadata`.
…richton Deny bare trait objects in in src/libpanic_unwind Enforce `#![deny(bare_trait_objects)]` in `src/libpanic_unwind`.
…r=oli-obk Deny bare trait objects in in src/librustc_codegen_utils Enforce `#![deny(bare_trait_objects)]` in `src/librustc_codegen_utils`.
@bors r+ p=10 |
📌 Commit a0b288e has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Jul 11, 2018
bors
added a commit
that referenced
this pull request
Jul 11, 2018
Rollup of 14 pull requests Successful merges: - #51614 (Correct suggestion for println) - #51952 ( hygiene: Decouple transparencies from expansion IDs) - #52193 (step_by: leave time of item skip unspecified) - #52207 (improve error message shown for unsafe operations) - #52223 (Deny bare trait objects in in src/liballoc) - #52224 (Deny bare trait objects in in src/libsyntax) - #52239 (Remove sync::Once::call_once 'static bound) - #52247 (Deny bare trait objects in in src/librustc) - #52248 (Deny bare trait objects in in src/librustc_allocator) - #52252 (Deny bare trait objects in in src/librustc_codegen_llvm) - #52253 (Deny bare trait objects in in src/librustc_data_structures) - #52254 (Deny bare trait objects in in src/librustc_metadata) - #52261 (Deny bare trait objects in in src/libpanic_unwind) - #52265 (Deny bare trait objects in in src/librustc_codegen_utils) Failed merges: r? @ghost
☀️ Test successful - status-appveyor, status-travis |
This was referenced Jul 11, 2018
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
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
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.
Successful merges:
Failed merges:
r? @ghost