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 #88596

Merged
merged 30 commits into from
Sep 2, 2021
Merged

Rollup of 12 pull requests #88596

merged 30 commits into from
Sep 2, 2021

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Sep 2, 2021

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

joshtriplett and others added 30 commits August 19, 2021 20:22
Co-authored-by: kennytm <kennytm@gmail.com>
Previously, `QueryJobInfo` was composed of two parts: a `QueryInfo` and
a `QueryJob`. However, both `QueryInfo` and `QueryJob` have a `span`
field, which seem to be the same. So, the `span` was recorded twice.

Now, `QueryJobInfo` is composed of a `QueryStackFrame` (the other field
of `QueryInfo`) and a `QueryJob`. So, now, the `span` is only recorded
once.
Instead, return `Type::Infer` since compilation should fail anyway.
That's how rustdoc handles `hir::TyKind::Err`s, so this just extends
that behavior to `ty::Err`s when analyzing associated types.

For some reason, the error is printed twice with rustdoc (though only
once with rustc). I'm not sure why that is, but it's better than
panicking.

This commit also makes rustdoc fail early in the non-projection,
non-error case, instead of returning a `Res::Err` that would likely
cause rustdoc to panic later on. This change is originally from rust-lang#88379.
…ou-se

Stabilize std::os::unix::fs::chroot

I've verified that this works as documented, and I've tested it in (a nightly
build of) production software as a replacement for an unsafe call to
`libc::chroot`. It's been available in nightly for a few releases. I think it's
ready to stabilize.

---

Tracking issue: rust-lang#84715
…=kennytm

Use `unwrap_unchecked` where possible
…, r=estebank

Upgrade array_into_iter lint to include Deref-to-array types.

Fixes rust-lang#88099

Fixes the issue mentioned here: rust-lang#84147 (comment)
`fmt::Formatter::pad`: don't call chars().count() more than one time

First commit merges two branches of match to call chars().count() only once: that should be faster if this method hits place of 3rd (previous) branch, plus quarter shorter.
Second commit fixes some clippy lints while i'm here (should it be separate PR?).
Add regression test for issue 83190

Reduced from `bioyino-metric` by ````@hellow554```` and myself.

Closes rust-lang#83190.

r? ````@spastorino````
Remove redundant `Span` in `QueryJobInfo`

Previously, `QueryJobInfo` was composed of two parts: a `QueryInfo` and
a `QueryJob`. However, both `QueryInfo` and `QueryJob` have a `span`
field, which seem to be the same. So, the `span` was recorded twice.

Now, `QueryJobInfo` is composed of a `QueryStackFrame` (the other field
of `QueryInfo`) and a `QueryJob`. So, now, the `span` is only recorded
once.
…laumeGomez

rustdoc: Don't panic on ambiguous inherent associated types

Instead, return `Type::Infer` since compilation should fail anyway.
That's how rustdoc handles `hir::TyKind::Err`s, so this just extends
that behavior to `ty::Err`s when analyzing associated types.

For some reason, the error is printed twice with rustdoc (though only
once with rustc). I'm not sure why that is, but it's better than
panicking.

This commit also makes rustdoc fail early in the non-projection,
non-error case, instead of returning a `Res::Err` that would likely
cause rustdoc to panic later on. This change is originally from rust-lang#88379.

r? `@GuillaumeGomez`
Implement rust-lang#88581

See rust-lang#88581 for details. This API was discussed on Zulip.

`@rustbot` label: +T-libs-api +S-waiting-on-review

r? `@joshtriplett`
…oc, r=petrochenkov

Correct doc comments inside `use_expr_visitor.rs`

Just a simple update. I haven't changed any content inside the comments, as they still seem correct. Have a wonderful rest of the day 🙃
@rustbot rustbot added the rollup A PR which is a rollup label Sep 2, 2021
@m-ou-se
Copy link
Member Author

m-ou-se commented Sep 2, 2021

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Sep 2, 2021

📌 Commit c082e15 has been approved by m-ou-se

@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 2, 2021
@bors
Copy link
Contributor

bors commented Sep 2, 2021

⌛ Testing commit c082e15 with merge b834c4c...

@bors
Copy link
Contributor

bors commented Sep 2, 2021

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing b834c4c to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 2, 2021
@bors bors merged commit b834c4c into rust-lang:master Sep 2, 2021
@rustbot rustbot added this to the 1.56.0 milestone Sep 2, 2021
@bors bors mentioned this pull request Sep 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.