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

Merged
merged 22 commits into from
Dec 29, 2021
Merged

Rollup of 7 pull requests #92397

merged 22 commits into from
Dec 29, 2021

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

compiler-errors and others added 22 commits December 27, 2021 12:20
The old name wasn't very clear, while the new one makes it clear that
this is the code responsible for creating the search index.
Based on
rust-lang#80883 (comment).
The `tcx` parameters do seem to be used though, so I only removed the
`cache` parameters.
It was previously defined in `render::search_index` but wasn't used at
all there. `clean::types` seems like a better fit since that's where
`ExternalCrate` is defined.
Now the only two crate-public items are `build_index` and
`get_index_search_type` (because for some reason the latter is also used
in `formats::cache`).
Variants are already handled by `resolve_str_path_error`, rustdoc doesn't need to consider them separately.
This issue was fixed using a hacky recursion "fuel" argument, but the
issue was never minimized nor was a regression test added. The
underlying bug is still unfixed, so this test should help with fixing it
and removing the `recurse` hack.
rustdoc: Only special case struct fields for intra-doc links, not enum variants

Variants are already handled by `resolve_str_path_error`, rustdoc doesn't need to consider them separately. Thanks `@camelid` for catching this!

Eventually I'd like to fix the "combine this with `variant_field`" comment but that needs `resolve_field` to take a `ty_res` parameter to avoid it being super hacky (cc rust-lang#83761 (comment)).

r? `@camelid`
… r=petrochenkov

Parse and suggest moving where clauses after equals for type aliases

~Mostly the same as rust-lang#90076, but doesn't make any syntax changes.~ Whether or not we want to land the syntax changes, we should  parse the invalid where clause position and suggest moving.

r? `@nikomatsakis`
cc `@petrochenkov` you might have thoughts on implementation
…llot

Visit expressions in-order when resolving pattern bindings

[edited:] Visit the pattern's sub-expressions before defining any bindings.

Otherwise, we might get into a case where a Lit/Range expression in a pattern has a qpath pointing to a Ident pattern that is defined after it, causing an ICE when lowering to HIR. I have a more detailed explanation in the issue linked.

Fixes rust-lang#92100
…llaumeGomez

rustdoc: Start cleaning up search index generation

I'm trying to simplify and clean up the code, partly to make rust-lang#90779 easier.

r? `@GuillaumeGomez`
Add long error explanation for E0227

Part of the rust-lang#61137.
Remove pretty printer space inside block with only outer attrs

Follow-up to rust-lang#92238 fixing one of the FIXMEs.

```rust
macro_rules! repro {
    ($expr:expr) => {
        stringify!($expr)
    };
}

fn main() {
    println!("{}", repro!(#[attr] {}));
}
```

Before: `#[attr] { }`
After: `#[attr] {}`
Print space after formal generic params in fn type

Follow-up to rust-lang#92238 fixing one of the FIXMEs.

```rust
macro_rules! repro {
    ($ty:ty) => {
        stringify!($ty)
    };
}

fn main() {
    println!("{}", repro!(for<'a> fn(&'a u8)));
}
```

Before:&ensp;`for<'a>fn(&'a u8)`
After:&ensp;`for<'a> fn(&'a u8)`

The pretty printer's `print_formal_generic_params` already prints formal generic params correctly with a space, we just need to call it when printing BareFn types instead of reimplementing the printing incorrectly without a space.

https://github.com/rust-lang/rust/blob/83b15bfe1c15f325bc186ebfe3691b729ed59f2b/compiler/rustc_ast_pretty/src/pprust/state.rs#L1394-L1400
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 29, 2021
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Dec 29, 2021

📌 Commit 949769c has been approved by matthiaskrgr

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

bors commented Dec 29, 2021

⌛ Testing commit 949769c with merge 2b67c30...

@bors
Copy link
Contributor

bors commented Dec 29, 2021

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 2b67c30 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 29, 2021
@bors bors merged commit 2b67c30 into rust-lang:master Dec 29, 2021
@rustbot rustbot added this to the 1.59.0 milestone Dec 29, 2021
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (2b67c30): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@matthiaskrgr matthiaskrgr deleted the rollup-xnfou17 branch January 2, 2022 22:34
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants