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 41 pull requests #57058

Closed
wants to merge 125 commits into from
Closed

Rollup of 41 pull requests #57058

wants to merge 125 commits into from

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Dec 22, 2018

Successful merges:

Failed merges:

r? @ghost

euclio and others added 30 commits December 14, 2018 11:15
RFC rust-lang#2195 specifies that a repr(int) enum such as:

    #[repr(u8)]
    enum MyEnum {
        B { x: u8, y: i16, z: u8 },
    }

has a layout that is equivalent to:

    #[repr(C)]
    enum MyEnumVariantB { tag: u8, x: u8, y: i16, z: u8 },

However this isn't actually implemented, with the actual layout being
roughly equivalent to:

    union MyEnumPayload {
        B { x: u8, y: i16, z: u8 },
    }

    #[repr(packed)]
    struct MyEnum {
        tag: u8,
        payload: MyEnumPayload,
    }

Thus the variant payload is *not* subject to repr(C) ordering rules, and
gets re-ordered as `{ x: u8, z: u8, z: i16 }`

The existing tests added in pull-req rust-lang#45688 fail to catch this as the
repr(C) ordering just happens to match the current Rust ordering in this
case; adding a third field reveals the problem.
This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld
to build LLVM on our dist builders for Linux. The goal of this is to
fix rust-lang#56849 by picking up a fix [1] in LLD.

Closes rust-lang#56849

[1]: llvm-mirror/lld@3be4e82
Layout size overflow and typeck eval errors are reported. Trigger a bug
only when the eval error is strictly labeled as TooGeneric.
logic is written up in rust-lang#49048

Also, update the documentation slightly
Remove pin::Unpin reexport and add Unpin to the prelude.
Change Pin associated functions to methods.
Rename get_mut_unchecked_ to get_unchecked_mut
Remove impl Unpin for Pin
Mark Pin repr(transparent)
…r=Manishearth

Mem uninit doc ptr drop

Extend the mem::uninitialized documentation to account for partially initialized arrays and how to correctly handle these. These are used in some datastructures (trees for example) or in FFI.

r? @Manishearth
make basic CTFE tracing available on release builds

Debugging things going wrong in miri is currently pretty much impossible with a nightly Rust.

r? @oli-obk
…nd-support, r=alexcrichton

Adding unwinding support for x86_64_fortanix_unknown_sgx target.

Unwinding support is provided by our port of LLVM's libunwind which is available from https://github.com/fortanix/libunwind/tree/release_50.

libunwind requires support for rwlock and printing to stderr, which is only provided by `std` for this target. This poses two problems: 1) how to expose the `std` functionality to C and 2) dependency inversion.

### Exposing `std`

For exposing the functionality we chose to expose the following symbols:

* __rust_rwlock_rdlock
* __rust_rwlock_wrlock
* __rust_rwlock_unlock
* __rust_print_err
* __rust_abort

Also, the following are needed from `alloc`:

* __rust_alloc
* __rust_dealloc

#### Rust RWLock in C

In `libunwind`, RWLock is initialized as a templated static variable:

```c
pthread_rwlock_t DwarfFDECache<A>::_lock = PTHREAD_RWLOCK_INITIALIZER;
```

I don't know of a good way to use the Rust sys::rwlock::RWLock type and initializer there. We could have a static global variable in Rust, but that doesn't work with the templating. The variable needs to be initialized statically, since this target doesn't support the .init section. Currently, I just used a byte array and standard C array initialization. The mapping between this C type and the Rust type needs to be manually maintained. There is a compile-time check and a unit test to make sure the Rust versions of these C definitions match the actual Rust type. If any reviewer knows of a better solution, please do tell.

### Dependency inversion issue

`std` depends on `panic_unwind` which depends on `libunwind`, and `libunwind` depends on `std`. This is not normally supported by Rust's linking system. Therefore we use raw C exports from `std` *and* `libunwind.a` is linked last in the target `post_link_objects` instead of being built as part of the Rust `libunwind`. Currently, all C exports are defined in `src/libstd/sys/sgx/rwlock.rs` to overcome LTO issues. Only the `__rust_rwlock_*` definitions *need* to live there for privacy reasons. Once again, if any reviewer knows of a better solution, please do tell.

r? @alexcrichton
…i-obk

A few tweaks to dropck_outlives

- remove an unnecessary call to `cloned()`
- simplify common patterns
…ations, r=Mark-Simulacrum

Fix compiletest `trim` deprecation warnings

None
…li-obk

suggest similar lint names for unknown lints

Fixes rust-lang#54737.
AST/HIR: Introduce `ExprKind::Err` for better error recovery in the front-end

This way we can avoid aborting compilation if expansion produces errors and generate `ExprKind::Err`s instead.
…=GuillaumeGomez

rustdoc: add new CLI flag to load static files from a different location

This PR adds a new CLI flag to rustdoc, `--static-root-path`, which controls how rustdoc links pages to the CSS/JS/font static files bundled with the output. By default, these files are linked with a series of `../` which is calculated per-page to link it to the documentation root - i.e. a relative link to the directory given by `-o`. This is causing problems for docs.rs, because even though docs.rs has saved one copy of these files and is dispatching them dynamically, browsers have no way of knowing that these are the same files and can cache them. This can allow it to link these files as, for example, `/rustdoc.css` instead of `../../rustdoc.css`, creating a single location that the files are loaded from.

I made sure to only change links for the *static* files, those that don't change between crates. Files like the search index, aliases, the source files listing, etc, are still linked with relative links.

r? @GuillaumeGomez

cc @onur
Enable emission of alignment attrs for pointer params

Instead disable creation of assumptions during inlining using an LLVM opt flag. For non-inlined functions, this gives us alignment information, while not inserting any assumes that kill other optimizations.

The `-Z arg-align-attributes` option which previously controlled this behavior is removed.

Fixes rust-lang#54982.

r? @nagisa

cc @eddyb who added the current behavior, and @scottmcm, who added the `-Z arg-align-attributes` flag.
…r=Centril

fix deprecation warnings in liballoc benches
…eature-gate, r=Centril

Fix feature gate to point to 1.32.0 for `path_from_str`

When the feature has been added back (rust-lang#55148) the feature gate has not
been adjusted accordingly. We have it enabled for 1.32.0, currently in
Beta, so adjust it.

Refs: rust-lang#44431.

Signed-off-by: Otavio Salvador <[email protected]>
Fixed typo in HashMap documentation

Previously "with a custom type as key", now "with a custom key type"
…arkor

Fix stabilization version numbers (exhaustive_integer_patterns + macro_literal_matcher)

+ `exhaustive_integer_patterns` slipped 1.32; merged in 1.33 -- rust-lang#56362
+ `macro_literal_matcher` isn't stable on current stable (1.31) but is on beta (1.32).

r? @varkor
Fix alignment for array indexing

We need to reduce the alignment with the used offset. If the offset isn't known, use the element size, as this will yield the minimum possible alignment.

This handles both direct array indexing, and array repeat expressions.

Fixes rust-lang#56927.

r? @nagisa
@Centril
Copy link
Contributor Author

Centril commented Dec 22, 2018

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Dec 22, 2018

📌 Commit aefca41 has been approved by Centril

@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 Dec 22, 2018
@bors
Copy link
Contributor

bors commented Dec 22, 2018

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout rollup (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self rollup --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Removing src/test/ui/feature-gates/feature-gate-repr_packed.stderr
Removing src/test/ui/feature-gates/feature-gate-repr_packed.rs
Auto-merging src/test/run-pass/issues/auxiliary/issue-31702-2.rs
Auto-merging src/test/run-pass/arbitrary_self_types_stdlib_pointers.rs
CONFLICT (content): Merge conflict in src/test/run-pass/arbitrary_self_types_stdlib_pointers.rs
Auto-merging src/libcore/pin.rs
CONFLICT (content): Merge conflict in src/libcore/pin.rs
Auto-merging src/liballoc/sync.rs
Auto-merging src/liballoc/rc.rs
Auto-merging src/liballoc/lib.rs
Auto-merging src/liballoc/boxed.rs
Removing src/doc/unstable-book/src/language-features/repr-packed.md
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 22, 2018
@bors
Copy link
Contributor

bors commented Dec 22, 2018

☔ The latest upstream changes (presumably #56805) made this pull request unmergeable. Please resolve the merge conflicts.

@kennytm kennytm closed this Dec 22, 2018
@Centril Centril deleted the rollup branch December 22, 2018 19:28
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
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-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.