-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Closed
Rollup of 9 pull requests #77483
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 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.
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.
Fix test name Remove trailing `-`.
…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
@bors r+ rollup=never p=5 |
📌 Commit 3f2a53f 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
Oct 3, 2020
⌛ Testing commit 3f2a53f with merge aa8c8696651a7043dd2e5468aa1cd65a7a82a301... |
💔 Test failed - checks-actions |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
tracing
spans to trace the entire MIR interp stack #75143 (Usetracing
spans to trace the entire MIR interp stack)handle_alloc_error
default to panic (for no_std + liballoc) #76448 (Implement Makehandle_alloc_error
default to panic (for no_std + liballoc))Failed merges:
r? @ghost