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 14 pull requests #52268

Merged
merged 39 commits into from
Jul 11, 2018
Merged

Rollup of 14 pull requests #52268

merged 39 commits into from
Jul 11, 2018

Conversation

Mark-Simulacrum
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

csmoe and others added 30 commits July 3, 2018 20:39
this gives us some leeway when optimizing
- [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.
 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`.
@Mark-Simulacrum
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Jul 11, 2018

📌 Commit a0b288e has been approved by Mark-Simulacrum

@bors 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
Copy link
Contributor

bors commented Jul 11, 2018

⌛ Testing commit a0b288e with merge 704af2d...

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
@bors
Copy link
Contributor

bors commented Jul 11, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: Mark-Simulacrum
Pushing 704af2d to master...

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants