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 12 pull requests #77240

Closed
wants to merge 28 commits into from
Closed

Rollup of 12 pull requests #77240

wants to merge 28 commits into from

Conversation

jonas-schievink
Copy link
Contributor

Successful merges:

Failed merges:

r? @ghost

JulianKnodt and others added 28 commits August 29, 2020 04:56
This tests both when there is the max amount of work(all characters used)
And least amount of work(1 character used)
Delimiters cannot appear as isolated tokens in a token stream
Use less divisions in display u128/i128

This PR is an absolute mess, and I need to test if it improves the speed of fmt::Display for u128/i128, but I think it's correct.
It hopefully is more efficient by cutting u128 into at most 2 u64s, and also chunks by 1e16 instead of just 1e4.

Also I specialized the implementations for uints to always be non-false because it bothered me that it was checked at all

Do not merge until I benchmark it and also clean up the god awful mess of spaghetti.
Based on prior work in #44583

cc: @Dylan-DPC

Due to work on `itoa` and suggestion in original issue:
r? @dtolnay
…Dylan-DPC

Add missing code examples on HashMap types

r? @Dylan-DPC
Refactor memchr to allow optimization

Closes #75659

The implementation already uses naive search if the slice if short enough, but the case is complicated enough to not be optimized away. This PR refactors memchr so that it exists early when the slice is short enough.

Codegen-wise, as shown in #75659, memchr was not inlined previously so the only way I could find to test this is to check if there is no memchr call. Let me know if there is a more robust solution here.
Add accessors to Command.

This adds some accessor methods to `Command` to provide a way to access the values set when building the `Command`. An example where this can be useful is to display the command to be executed. This is roughly based on the [`ProcessBuilder`](https://github.com/rust-lang/cargo/blob/13b73cdaf76b2d9182515c9cf26a8f68342d08ef/src/cargo/util/process_builder.rs#L105-L134) in Cargo.

Possible concerns about the API:
- Values with NULs on Unix will be returned as `"<string-with-nul>"`. I don't think it is practical to avoid this, since otherwise a whole separate copy of all the values would need to be kept in `Command`.
- Does not handle `arg0` on Unix. This can be awkward to support in `get_args` and is rarely used. I figure if someone really wants it, it can be added to `CommandExt` as a separate method.
- Does not offer a way to detect `env_clear`. I'm uncertain if it would be useful for anyone.
- Does not offer a way to get an environment variable by name (`get_env`). I figure this can be added later if anyone really wants it. I think the motivation for this is weak, though. Also, the API could be a little awkward (return a `Option<Option<&OsStr>>`?).
- `get_envs` could skip "cleared" entries and just return `&OsStr` values instead of `Option<&OsStr>`. I'm on the fence here. My use case is to display a shell command, and I only intend it to be roughly equivalent to the actual execution, and I probably won't display `None` entries. I erred on the side of providing extra information, but I suspect many situations will just filter out the `None`s.
- Could implement more iterator stuff (like `DoubleEndedIterator`).

I have not implemented new std items before, so I'm uncertain if the existing issue should be reused, or if a new tracking issue is needed.

cc #44434
Enable const propagation into operands at mir_opt_level=2

Feature was added in #74507 but gated with `mir_opt_level>=3` because of compile time regressions. Let's see whether the LLVM 11 update solves that.

As the [perf results](#77107 (comment)) show, enabling this optimization results in a lot less regression as before.

cc @oli-obk

r? @ghost
Update cargo

7 commits in 8777a6b1e8834899f51b7e09cc9b8d85b2417110..05c611ae3c4255b7a2bcf4fcfa65b20286a07839
2020-09-15 19:11:03 +0000 to 2020-09-23 23:10:38 +0000
- --workspace flag for locate-project to find the workspace root (rust-lang/cargo#8712)
- Remove some badges documentation. (rust-lang/cargo#8727)
- Add plain message format for locate-project (rust-lang/cargo#8707)
- Add a term option to configure the progress bar (rust-lang/cargo#8165)
- Replace d_as_f64 with as_secs_f64 (rust-lang/cargo#8721)
- Add cross check to filters_target test. (rust-lang/cargo#8713)
- Add test for whitespace behavior in env flags. (rust-lang/cargo#8706)
…ign-test, r=nagisa

Fix FIXME in core::num test: Check sign of zero in min/max tests.

r? nagisa

@rustbot modify labels: +C-cleanup
Rust vec bench import specific rand::RngCore

Using `RngCore` import for side effects is clearer than `*` which may bring it unnecessary more stuff than needed, it is also more explicit doing so.

@pickfire change `LEN = 16384` (and pos) and `once` instead of `[0].iter()` after this.

@rustbot modify labels: +C-cleanup +A-testsuite
Late link args order

MSYS2 changed how winpthreads is built and as the result it now depends on more mingw-w64 libraries.

This PR affects only MinGW targets since nobody else is using `late_link_args_{dynamic,static}`. Now the order is similar to how it used to be before #67502.
Move helper function for `missing_const_for_fn` out of rustc to clippy

cc @rust-lang/clippy @ecstatic-morse #76618

r? @Manishearth

I also removed all support for suggesting a function could be `const fn` when that would require feature gates to actually work.

This means we'll now have to maintain this ourselves in clippy, but that's how most lints work anyway, so...
pretty-print-reparse hack: Rename some variables for clarity

This will also make it easier to make the comparisons asymmetric.

Also one impossible case is removed.

r? @Aaron1011
@jonas-schievink
Copy link
Contributor Author

@bors r+ rollup=never p=12

@rustbot modify labels: rollup

@bors
Copy link
Contributor

bors commented Sep 26, 2020

📌 Commit fb98604 has been approved by jonas-schievink

@rustbot rustbot added the rollup A PR which is a rollup label Sep 26, 2020
@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 Sep 26, 2020
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-8 of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
Initialized empty Git repository in /home/runner/work/rust/rust/.git/
##[command]git remote add origin https://github.com/rust-lang/rust
##[command]git config gc.auto 0
##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/77240/merge:refs/remotes/pull/77240/merge
---
   Compiling libc v0.2.77
   Compiling std v0.0.0 (/checkout/library/std)
   Compiling compiler_builtins v0.1.35
   Compiling unwind v0.0.0 (/checkout/library/unwind)
error[E0599]: no function or associated item named `first_ptr_mut` found for union `mem::maybe_uninit::MaybeUninit<_>` in the current scope
   --> library/core/src/fmt/num.rs:484:32
    |
484 |     let buf_ptr = MaybeUninit::first_ptr_mut(buf);
    |                                ^^^^^^^^^^^^^ function or associated item not found in `mem::maybe_uninit::MaybeUninit<_>`
   ::: library/core/src/mem/maybe_uninit.rs:221:1
    |
221 | pub union MaybeUninit<T> {
221 | pub union MaybeUninit<T> {
    | ------------------------ function or associated item `first_ptr_mut` not found for this

error[E0599]: no function or associated item named `first_ptr_mut` found for union `mem::maybe_uninit::MaybeUninit<_>` in the current scope
   --> library/core/src/fmt/num.rs:598:32
    |
598 |     let buf_ptr = MaybeUninit::first_ptr_mut(&mut buf);
    |                                ^^^^^^^^^^^^^ function or associated item not found in `mem::maybe_uninit::MaybeUninit<_>`
   ::: library/core/src/mem/maybe_uninit.rs:221:1
    |
221 | pub union MaybeUninit<T> {
221 | pub union MaybeUninit<T> {
    | ------------------------ function or associated item `first_ptr_mut` not found for this
error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `core`.
---
== clock drift check ==
  local time: Sat Sep 26 21:03:05 UTC 2020
  network time: Sat, 26 Sep 2020 21:03:05 GMT
== end clock drift check ==
##[error]Process completed with exit code 1.
Terminate orphan process: pid (2947) (node)
Terminate orphan process: pid (2956) (python)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

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.

None yet