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 10 pull requests #82330

Closed
wants to merge 35 commits into from

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

gilescope and others added 30 commits February 6, 2021 19:56
Following rust-lang#78026, `std::fs::hard_link` on most platforms does not follow
symlinks. Change the WASI implementation to also not follow symlinks.
This does not suggest adding such a function to the public API. This is
just for the purpose of avoiding duplicate code. Many array methods
already contained the same kind of code and there are still many array
related methods to come (e.g. `Iterator::{chunks, map_windows, next_n,
...}`) which all basically need this functionality. Writing custom
`unsafe` code for each of those seems not like a good idea.
It's not possible to check if removing a semicolon fixes the type error
when checking match arms and one or both of the last arm's and the
current arm's return types are imported "opaque" types. In these cases
we don't generate a "consider removing semicolon" suggestions.

Fixes rust-lang#81839
Changes from 81473 extended the dead code lint with an ability to detect
fields that are written to but never read from. The implementation skips
over fields on the left hand side of an assignment, without marking them
as live.

A field access might involve an automatic dereference and de-facto read
the field. Conservatively mark expressions with deref adjustments as
live to avoid generating false positive warnings.
Also fixes the "since" version of the original.
`impl PartialEq<Punct> for char`; symmetry for rust-lang#78636

Also fixes the "since" version of the original.

Pinging `@dtolnay` and `@petrochenkov.`
Slight perf improvement on char::to_ascii_lowercase

`char::to_ascii_lowercase()` was checking if it was ascii and then if it was in the right range. Instead propose to check once (I think removing a compare and a shift in the process: [godbolt](https://godbolt.org/z/e5Tora) ).

before:
```
        test char::methods::bench_to_ascii_lowercase                    ... bench:      11,196 ns/iter (+/- 632)
        test char::methods::bench_to_ascii_uppercase                    ... bench:      11,656 ns/iter (+/- 671)
```
after:
```
         test char::methods::bench_to_ascii_lowercase                    ... bench:       9,612 ns/iter (+/- 979)
         test char::methods::bench_to_ascii_uppercase                    ... bench:       8,241 ns/iter (+/- 701)
```

(calling u8::to_ascii_lowercase and letting that flip the 5th bit is also an option, but it's more instructions. I'm thinking for things around ascii and char we want to be as efficient as possible.)
Make WASI's `hard_link` behavior match other platforms.

Following rust-lang#78026, `std::fs::hard_link` on most platforms does not follow
symlinks. Change the WASI implementation to also not follow symlinks.

r? `@alexcrichton`
Fix panic in 'remove semicolon' when types are not local

It's not possible to check if removing a semicolon fixes the type error
when checking match arms and one or both of the last arm's and the
current arm's return types are imported "opaque" types. In these cases
we don't generate a "consider removing semicolon" suggestions.

Fixes rust-lang#81839

---

I'm not sure how to add a test for this. I think the test would need at least two crates. Do we have any existing tests that do this so that I can take a look?
… r=RalfJung

use PlaceRef abstractions more consistently

Addresses this [comment](https://github.com/rust-lang/rust/pull/80865/files#r558978715)
Associated issue: rust-lang#80647

r? `@RalfJung`
…ray, r=dtolnay

Add internal `collect_into_array[_unchecked]` to remove duplicate code

Unlike the similar PRs  rust-lang#69985, rust-lang#75644 and rust-lang#79659, this PR only adds private functions and does not propose any new public API. The change is just for the purpose of avoiding duplicate code.

Many array methods already contained the same kind of code and there are still many array related methods to come (e.g. `Iterator::{chunks, map_windows, next_n, ...}`, `[T; N]::{cloned, copied, ...}`, ...) which all basically need this functionality. Writing custom `unsafe` code for each of those doesn't seem like a good idea. I added two functions in this PR (and not just the `unsafe` version) because I already know that I need the `Option`-returning version for `Iterator::map_windows`.

This is closely related to rust-lang#81615. I think that all options listed in that issue can be implemented using the function added in this PR. The only instance where `collect_array_into` might not be general enough is when the caller want to handle incomplete arrays manually. Currently, if `iter` yields fewer than `N` items, `None` is returned and the already yielded items are dropped. But as this is just a private function, it can be made more general in future PRs.

And while this was not the goal, this seems to lead to better assembly for `array::map`: https://rust.godbolt.org/z/75qKTa (CC `@JulianKnodt)`

Let me know what you think :)

CC `@matklad` `@bstrie`
add s390x-unknown-linux-musl target

This is the first step in bringup for Rust on s390x.

The libc and std crates need modifications as well, but getting this upstream makes that work easier.
fix MIR fn-ptr pretty-printing

An uninitialized function pointer would get printed as `{{uninit  fn()}` (notice the unbalanced parentheses), and a dangling fn ptr would ICE. This fixes both of that.

However, I have no idea how to add tests for this.

Also, I don't understand this MIR pretty-printing code. Somehow the print function `pretty_print_const_scalar` actually *returns* a transformed form of the const (but there is no doc comment explaining what is being returned); some match arms do `p!` while others do `self =`, and there's a wild mixture of `p!` and `write!`... all very mysterious and confusing.^^

r? `@oli-obk`
Support `pub` on `macro_rules`

This rebases and updates `since` version of rust-lang#78166 from `@petrochenkov`

r? `@nikomatsakis`
Consider auto derefs before warning about write only fields

Changes from rust-lang#81473 extended the dead code lint with an ability to detect
fields that are written to but never read from. The implementation skips
over fields on the left hand side of an assignment, without marking them
as live.

A field access might involve an automatic dereference and de-facto read
the field. Conservatively mark expressions with deref adjustments as
live to avoid generating false positive warnings.

Closes rust-lang#81626.
@rustbot rustbot added the rollup A PR which is a rollup label Feb 20, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 20, 2021

📌 Commit 3b80aef 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 Feb 20, 2021
@bors
Copy link
Contributor

bors commented Feb 20, 2021

⌛ Testing commit 3b80aef with merge f63c4ea80e3dd63e62918b4f996868a5d6680759...

@bors
Copy link
Contributor

bors commented Feb 20, 2021

💔 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 Feb 20, 2021
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors
Copy link
Contributor

bors commented Feb 21, 2021

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

@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-q9869pk branch February 21, 2021 16:24
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-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.