-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 19 pull requests #38943
Rollup of 19 pull requests #38943
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
@bors r+ p=10 |
📌 Commit 6911425 has been approved by |
@bors r- |
A fairly common workflow is to put a bunch of stuff into a binary heap and then mutate the top value until its empty. This both makes that a bit more convenient (no need to save a boolean off and pop after to avoid borrowck issues), and a bit more efficient since you only shift once.
It was used to measure before/after size in cfaf66c.
`BoolTrie` works well for sets of code points spread out through most of Unicode’s range, but is uses a lot of space for sets with few, mostly low, code points. This switches a few of its instances to a similar but simpler trie data structure. ## Before `size_of::<BoolTrie>()` is 1552, which is added to `table.r3.len() * 8 + t.r5.len() + t.r6.len() * 8`: * `Cc_table`: 1632 * `White_Space_table`: 1656 * `Pattern_White_Space_table`: 1640 * Total: 4928 bytes ## After `size_of::<SmallBoolTrie>()` is 32, which is added to `t.r1.len() + t.r2.len() * 8`: * `Cc_table`: 51 * `White_Space_table`: 273 * `Pattern_White_Space_table`: 193 * Total: 517 bytes ## Difference Every Rust program with `std` statically linked should be about 4 KB smaller.
The `-Wl` option splits its parameters on commas, so if rustc specifies `-Wl,-rpath,<path>` when `<path>` contains commas, the path gets split up and the linker gets a partial path and spurious extra parameters. Gcc/clang support the more verbose `-Xlinker` option to pass options to the linker directly, so use it for comma-containing paths. Fixes rust issue rust-lang#38795.
Local testing showed that I was able to reproduce an error where debuginfo tests on Android would fail with "connection reset by peer". Further investigation turned out that the gdb tests are android with bit of process management: * First an `adb forward` command is run to ensure that the host's port 5039 is the same as the emulator's. * Next an `adb shell` command is run to execute the `gdbserver` executable inside the emulator. This gdb server will attach to port 5039 and listen for remote gdb debugging sessions. * Finally, we run `gdb` on the host (not in the emulator) and then connect to this gdb server to send it commands. The problem was happening when the host's gdb was failing to connect to the remote gdbserver running inside the emulator. The previous test for this was that after `adb shell` executed we'd sleep for a second and then attempt to make a TCP connection to port 5039. If successful we'd run gdb and on failure we'd sleep again. It turns out, however, that as soon as we've executed `adb forward` all TCP connections to 5039 will succeed. This means that we would only ever sleep for at most one second, and if this wasn't enough time we'd just fail later because we would assume that gdbserver had started but it may not have done so yet. This commit fixes these issues by removing the TCP connection to test if gdbserver is ready to go. Instead we read the stdout of the process and wait for it to print that it's listening at which point we start running gdb. I've found that locally at least I was unable to reproduce the failure after these changes. Closes rust-lang#38710
Historically this was done to accommodate bugs in lints, but there hasn't been a bug in a lint since this feature was added which the warnings affected. Let's completely purge warnings from all our stages by denying warnings in all stages. This will also assist in tracking down `stage0` code to be removed whenever we're updating the bootstrap compiler.
The `doc-book` and `doc-nomicon` steps accidentally depended on a rustbook compiled by a cross-compiled compiler, which isn't necessary. Be sure to set the `host` on these dependency edges to the build compiler to ensure that we're always using a tool compiled for the host platform. This was discovered trawling the build logs for the new dist bots and discovering that they're building one too many compilers in stage0.
Adding it in a stable form was an accident. It thankfully only leaked to nightly. Fixes rust-lang#38860
Let's try to squash some of those network issues with a `travis_retry` tool to just retry the command a few times.
Try to handle spurious network failures on Travis by automatically retrying failed downloads on Travis.
This commit adds a new method to the `Child` type in the `std::process` module called `try_wait`. This method is the same as `wait` except that it will not block the calling thread and instead only attempt to collect the exit status. On Unix this means that we call `waitpid` with the `WNOHANG` flag and on Windows it just means that we pass a 0 timeout to `WaitForSingleObject`. Currently it's possible to build this method out of tree, but it's unfortunately tricky to do so. Specifically on Unix you essentially lose ownership of the pid for the process once a call to `waitpid` has succeeded. Although `Child` tracks this state internally to be resilient to multiple calls to `wait` or a `kill` after a successful wait, if the child is waited on externally then the state inside of `Child` is not updated. This means that external implementations of this method must be extra careful to essentially not use a `Child`'s methods after a call to `waitpid` has succeeded (even in a nonblocking fashion). By adding this functionality to the standard library it should help canonicalize these external implementations and ensure they can continue to robustly reuse the `Child` type from the standard library without worrying about pid ownership.
Warning or error messages set via a lint group attribute (e.g. `#[deny(warnings)]`) should still make it clear which individual lint (by name) was triggered, similarly to how we include "on by default" language for default lints. This—and, while we're here, the existing "on by default" language—can be tucked into a note rather than cluttering the main error message. This occasions the slightest of refactorings (we now have to get the diagnostic-builder with the main message first, before matching on the lint source). This is in the matter of rust-lang#36846.
Previously, the note/message for the source of a lint being the command line unconditionally named the individual lint, even if the actual command specified a lint group (e.g., `-D warnings`); here, we take note of the actual command options so we can be more specific. This remains in the matter of rust-lang#36846.
As suggested by Niko Matsakis in review (rust-lang#38103 (comment)) regarding the endeavor prompted by rust-lang#36846.
Due to rust-lang#28728 loop {} is very risky and can lead to fun debugging experiences like in rust-lang#38136. Besides, aborting is probably better behavior than an infinite loop.
As per @alexcrichton's comment in rust-lang#38607.
We don't actually use trampoline_setup.c and all the `*tf3` business seems related to f80/f128 business. Specifically this'll fix some warnings showing up during builds on OSX.
Sign formatting is no longer controlled by a `Signed` trait. Instead, `pad_integral` is used and implemented for numeric types by default. Fixes rust-lang#38677
Add proc_macro crate type
Add a warning not to convert char* from c to Vec<u8> (I thought you could until I asked on irc)
Changed language to stress char is the C meaning (u8) not unicode.
bors seemed to pull in commits here that I didn't specify for the rollup, so I'm bailing on this. |
VecDeque::insert
. #38581, Add test for correct span for type #38606, Test for appropriate span on second custom derive #38607, std: Remove unused objects from compiler-builtins #38623, Fix doc forescape_debug
#38629, Replace uses of#[unsafe_destructor_blind_to_params]
with#[may_dangle]
#38664, Update sign formatting for numeric types in docs #38704, Doc fix #38799, Add more docs for CoerceUnsized and Unsize #38816, Fix typo in tuple docs #38836, Expand {Path,OsStr}::{to_str,to_string_lossy} doc examples. #38839, Update usage of rustc #38841, ICH: Add some more test cases for trait impls. #38849, Update vec.rs #38874