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 9 pull requests #77483

Closed
wants to merge 41 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost

CAD97 and others added 30 commits September 12, 2020 10:27
This unifies it with the handling of `target-feature=+crt-static` on
other platforms, and allows for supporting static glibc in the future.
With this change, it's possible to build on a linux-gnu target and pass
RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a
`.cargo/config.toml` file, and get a statically linked executable.

Update to libc 0.2.78, which adds support for static linking with glibc.

Add `crt_static_respected` to the `linux_base` target spec.

Update `android_base` and `linux_musl_base` accordingly. Avoid enabling
crt_static_respected on Android platforms, since that hasn't been
tested.
This commit improves the way build-manifest calculates the checksums
included in the manifest, speeding it up:

* Instead of calculating all the hashes beforehand and then using the
  ones we need, the manifest is first generated with placeholder hashes,
  and then a function walks through the manifest and calculates only the
  needed checksums.

* Calculating the checksums is now done in parallel with rayon, to
  better utilize all the available disk bandwidth.

* Calculating the checksums now uses the sha2 crate instead of the
  sha256sum CLI tool: this avoids the overhead of calling another
  process, but more importantly uses hardware acceleration whenever
  available (the CLI tool doesn't support it at all).
This avoids overloading the old server, and disrupting the other
programs running on it.
…balloc)

Related: rust-lang#66741

Guarded with `#![feature(default_alloc_error_handler)]` a default
`alloc_error_handler` is called, if a custom allocator is used and no
other custom `#[alloc_error_handler]` is defined.

The panic message does not contain the size anymore, because it would
pull in the fmt machinery, which would blow up the code size
significantly.
Remove trailing `-`.
The previous error was confusing since it made it sound like you can't
link to items that are defined outside the current module.

Also suggested importing the item.
The new error was confusing when there was partial resolution (something
like `std::io::nonexistent`); the old one is better for those cases.
camelid and others added 11 commits October 2, 2020 19:53
Allow Weak::as_ptr and friends for unsized T

Relaxes `impl<T> Weak<T>` to `impl<T: ?Sized> Weak<T>` for the methods `rc::Weak::as_ptr`, `into_raw`, and `from_raw`.

Follow-up to rust-lang#73845, which did most of the impl work to make these functions work for `T: ?Sized`.

We still have to adjust the implementation of `Weak::from_raw` here, however, because I missed a use of `ptr.is_null()` previously. This check was necessary when `into`/`from_raw` were first implemented, as `into_raw` returned `ptr::null()` for dangling weak. However, we now just (wrapping) offset dangling weaks' pointers the same as nondangling weak, so the null check is no longer necessary (or even hit). (I can submit just 17a928f as a separate PR if desired.)

As a nice side effect, moves the `fn is_dangling` definition closer to `Weak::new`, which creates the dangling weak.

This technically stabilizes that "something like `align_of_val_raw`" is possible to do. However, I believe the part of the functionality required by these methods here -- specifically, getting the alignment of a pointee from a pointer where it may be dangling iff the pointee is `Sized` -- is uncontroversial enough to stabilize these methods without a way to implement them on stable Rust.

r? @RalfJung, who reviewed rust-lang#73845.

ATTN: This changes (relaxes) the (input) generic bounds on stable fn!
Use `tracing` spans to trace the entire MIR interp stack

r? @RalfJung

While being very verbose, this allows really good tracking of what's going on. While I considered schemes like the previous indenter that we had (which we could get by using the `tracing-tree` crate), this will break down horribly with things like multithreaded rustc. Instead, we can now use `RUSTC_LOG` to restrict the things being traced. You could specify a filter in a way that only shows the logging of a specific frame.

![screenshot of command line output of the new formatting](https://user-images.githubusercontent.com/332036/89291343-aa40de00-d65a-11ea-9f6c-ea06c1806327.png)

If we lower the span's level to `debug`, then in `info` level logging we'd not see the frames, but in `debug` level we would see them. The filtering rules in `tracing` are super powerful, but  I'm not sure if we can specify a filter so we do see `debug` level events, but *not* the `frame` spans. The documentation at https://docs.rs/tracing-subscriber/0.2.10/tracing_subscriber/struct.EnvFilter.html makes me think that we can only turn on things, not turn off things at a more precise level.

cc @hawkw
…chenkov

Uplift drop-bounds lint from clippy

Bounds on `T: Drop` do nothing, so they should warn.
…_reduced, r=Amanieu

Implement Make `handle_alloc_error` default to panic (for no_std + liballoc)

Related: rust-lang#66741

Guarded with `#![feature(default_alloc_error_handler)]` a default
`alloc_error_handler` is called, if a custom allocator is used and no
other custom `#[alloc_error_handler]` is defined.
…henkov

Support static linking with glibc and target-feature=+crt-static

With this change, it's possible to build on a linux-gnu target and pass
RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a
`.cargo/config.toml` file, and get a statically linked executable.

Update to libc 0.2.78, which adds support for static linking with glibc.

Add `crt_static_respected` to the `linux_base` target spec.

Update `android_base` and `linux_musl_base` accordingly. Avoid enabling
crt_static_respected on Android platforms, since that hasn't been
tested.

Closes rust-lang#65447.
Add some regression tests

Closes rust-lang#66501
Closes rust-lang#68951
Closes rust-lang#72565
Closes rust-lang#74244
Closes rust-lang#75299

The first issue is fixed in 1.43.0, other issues are fixed in the recent nightly.
…=Mark-Simulacrum

Improve build-manifest to work with the improved promote-release

This PR makes some changes to build-manifest to have it work better with the other improvements I'm making to [promote-release](https://github.com/rust-lang/promote-release).

A new way to invoke the tool was added: `./x.py run src/tools/build-manifest`. The new invocation disables the generation of `.sha256` files and the generation of GPG signatures, as those steps are not tied to the Rust version we're building the manifest of: handling them in `promote-release` will improve the maintenability of our release process. Invocations through the old command (`./x.py dist hash-and-sign`) are referred inside the source code as "legacy". The new invocation also enables internal parallelism, disabled on legacy to avoid overloading our old server.

Improvements were also made on how the checksums included in the manifest are generated:

* The manifest is first generated with placeholder checksums, and then a function walks through the manifes and calculates only the needed hashes. Before this PR, all the hashes were calculated beforehand, including the hashes of unused files.
* Calculating the hashes is now done in parallel with rayon, to better utilize all the available disk bandwidth.
* The `sha2` crate is now used instead of the `sha256sum` CLI tool: this avoids the overhead of calling another process, but more importantly enables hardware acceleration whenever available (the `sha256sum` CLI tool doesn't support it at all).

r? @Mark-Simulacrum
This PR is best reviewed commit-by-commit.
…rror, r=jyn514

Improve rustdoc error for failed intra-doc link resolution

The previous error was confusing since it made it sound like you can't
link to items that are defined outside the current module.

Also suggested importing the item.

r? @jyn514
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Oct 3, 2020

📌 Commit 3f2a53f has been approved by Dylan-DPC

@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 Oct 3, 2020
@bors
Copy link
Contributor

bors commented Oct 3, 2020

⌛ Testing commit 3f2a53f with merge aa8c8696651a7043dd2e5468aa1cd65a7a82a301...

@bors
Copy link
Contributor

bors commented Oct 3, 2020

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 3, 2020
@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-eaa8mrj branch October 3, 2020 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.