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 7 pull requests #83777

Closed
wants to merge 15 commits into from
Closed

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

camelid and others added 15 commits March 21, 2021 20:09
It is tightly connected to `Context` and is primarily used as a field in
`Context`. Thus, it should be next to `Context`.
When other errors are generated, there can be a mismatch between the
amount of input types in MIR, and the amount in the function itself.
Break from the comparative loop if this is the case to prevent
out-of-bounds.
Add a test that has the right input to trigger an out-of-bounds
error when in MIR the local_decls and the normalized_input_tys don't
match in amount.
Instead, only load the crates that are linked to with intra-doc links.

This doesn't help very much with any of rustdoc's fundamental issues
with freezing the resolver, but it at least fixes a stable-to-stable
regression, and makes the crate loading model somewhat more consistent
with rustc's.
Beginning with FreeBSD 10.4 and 11.1, there is one guard page by
default.  And the stack autoresizes, so if Rust allocates its own guard
page, then FreeBSD's will simply move up one page.  The best solution is
to just use the OS's guard page.
…aumeGomez

Move `SharedContext` to `context.rs`

It is tightly connected to `Context` and is primarily used as a field in
`Context`. Thus, it should be next to `Context`.
…r=nikomatsakis

Break when there is a mismatch in the type count

When other errors are generated, there can be a mismatch between the
amount of input types in MIR, and the amount in the function itself.
Break from the comparative loop if this is the case to prevent
out-of-bounds.
Fixes rust-lang#83499
…rochenkov

rustdoc: Don't load all extern crates unconditionally

Instead, only load the crates that are linked to with intra-doc links.

This doesn't help very much with any of rustdoc's fundamental issues
with freezing the resolver, but it at least fixes a stable-to-stable
regression, and makes the crate loading model somewhat more consistent
with rustc's. I tested and it unfortunately does not help at all with rust-lang#82496.

Closes rust-lang#68427. Let me know if you want me to open a separate issue for not freezing the resolver.
r? `@petrochenkov` cc `@eddyb` `@ollie27`
Fix comment typo in once.rs

I believe I came across a minor typo in a comment. I am not particularly familiar with this part of the codebase, but I have read the surrounding code as well as the referenced `park` and `unpark` functions, and I believe my proposed change is true to the intended meaning of the comment.

I intentionally tried to keep the change as minimal as possible. If I have the maintainers' permission, I'd also love to add a comma to improve readability as follows: `Luckily ``park`` comes with the guarantee that if it got an ``unpark`` just before on an unparked thread, it does not park.`
…mulacrum

Add my new email address to .mailmap
…, r=jyn514

Add test to ensure search tabs behaviour

It adds a GUI test for rust-lang#80382.

r? `@jyn514`
…tolnay

Fix stack overflow detection on FreeBSD 11.1+

Beginning with FreeBSD 10.4 and 11.1, there is one guard page by
default.  And the stack autoresizes, so if Rust allocates its own guard
page, then FreeBSD's will simply move up one page.  The best solution is
to just use the OS's guard page.
@rustbot rustbot added the rollup A PR which is a rollup label Apr 2, 2021
@JohnTitor
Copy link
Member Author

@bors r+ p=7 rollup=never

@bors
Copy link
Contributor

bors commented Apr 2, 2021

📌 Commit 9b8583a has been approved by JohnTitor

@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 Apr 2, 2021
@rust-log-analyzer
Copy link
Collaborator

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
    Checking rustdoc v0.0.0 (/checkout/src/librustdoc)
error[E0412]: cannot find type `TyCtxt` in this scope
   --> src/librustdoc/html/render/mod.rs:865:10
    |
865 |     tcx: TyCtxt<'_>,
    |
help: consider importing one of these items
    |
35  | use crate::TyCtxt;
35  | use crate::TyCtxt;
    |
35  | use rustc_middle::ty::TyCtxt;
    |

error[E0412]: cannot find type `TyCtxt` in this scope
    --> src/librustdoc/html/render/mod.rs:1272:61
     |
1272 | fn spotlight_decl(decl: &clean::FnDecl, cache: &Cache, tcx: TyCtxt<'_>) -> String {
     |
help: consider importing one of these items
     |
35   | use crate::TyCtxt;
35   | use crate::TyCtxt;
     |
35   | use rustc_middle::ty::TyCtxt;
     |

error[E0412]: cannot find type `TyCtxt` in this scope
    --> src/librustdoc/html/render/mod.rs:2052:10
     |
2052 |     tcx: TyCtxt<'_>,
     |
help: consider importing one of these items
     |
35   | use crate::TyCtxt;
35   | use crate::TyCtxt;
     |
35   | use rustc_middle::ty::TyCtxt;
     |

error[E0412]: cannot find type `TyCtxt` in this scope
    --> src/librustdoc/html/render/mod.rs:2064:10
     |
2064 |     tcx: TyCtxt<'_>,
     |
help: consider importing one of these items
     |
35   | use crate::TyCtxt;

@JohnTitor
Copy link
Member Author

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 2, 2021
@JohnTitor JohnTitor closed this Apr 2, 2021
@JohnTitor JohnTitor deleted the rollup-h8aatpz branch April 2, 2021 09:02
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-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants