Rollup of 7 pull requests #95990
Merged
Rollup of 7 pull requests #95990
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit fixes a corner case in `suggest_constraining_type_params`
that was causing incorrect suggestions.
For the following functions:
```rust
fn a<T:>(t: T) { [t, t]; }
fn b<T>(t: T) where T: { [t, t]; }
```
We previously suggested the following:
```text
...
help: consider restricting type parameter `T`
|
1 | fn a<T: Copy:>(t: T) { [t, t]; }
| ++++++
...
help: consider further restricting this bound
|
2 | fn b<T>(t: T) where T: + Copy { [t, t]; }
| ++++++
```
Note that neither `T: Copy:` not `where T: + Copy` is a correct bound.
With this commit the suggestions are correct:
```text
...
help: consider restricting type parameter `T`
|
1 | fn a<T: Copy>(t: T) { [t, t]; }
| ++++
...
help: consider further restricting this bound
|
2 | fn b<T>(t: T) where T: Copy { [t, t]; }
| ++++
```
Co-authored-by: Michael Goulet <michael@errs.io> Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
…-consts-tys, r=notriddle,GuillaumeGomez Rustdoc: Discriminate required and provided associated constants and types Currently, rustdoc merely separates required and provided associated _functions_ (i.e. methods). This PR extends this to constants (fixes rust-lang#94652) and types. This makes the documentation of all three kinds of associated items more alike and consistent. As an aside, associated types may actually be provided / have a default when users enable the unstable feature `associated_type_defaults`. | Before | After | |---|---| |  |  | |  |  | ### `clean::types::ItemKind` modification * `ItemKind::TypedefItem(.., true)` → `ItemKind::AssocTypeItem(..)` * `ItemKind::TypedefItem(.., false)` → `ItemKind::TypedefItem(..)` Further, I added `ItemKind::TyAssoc{Const,Type}Item`, the “required” variant of `ItemKind::Assoc{Const,Type}Item`, analogous to `ItemKind::TyMethodItem` with `ItemKind::MethodItem`. These new variants don't contain new information really, they are just the result of me getting rid of the `Option<_>` field in `AssocConstItem` and `AssocTypeItem`. **Goal**: Make associated items more consistent. Originally I thought modifying `ItemKind` was necessary to achieve the new functionality of this PR but in retrospect, it does not. If you don't like the changes to `ItemKind`, I think I _can_ get rid of them. This change is the root cause of those tiny changes in a lot of different files. ### Concerns and Open Questions * **breaking changes** to hyperlinks: Some heading IDs change: * `associated-const` (sic!) -> `{provided,required}-associated-consts` * `associated-types` -> `{provided,required}-associated-types` * **verbosity** of the headings _{Required,Provided} Associated {Constants,Types}_ * For some files, I am not sure if the changes I made are correct. So please take extra care when reviewing `conversions.rs` (conversion to JSON), `cache.rs`/`fold_item`, `stripper.rs`/`fold_item`, `check_doc_test_visibility.rs`/`should_have_doc_example`, `collect_intra_doc_links.rs`/`from_assoc_item` * JSON output: I still map `AssocTypeItem`s to `Typedef` etc. (FIXME)
Move name resolution logic to a dedicated file The code resolution logic from an Ident is scattered between several files. The first commits creates `rustc_resolve::probe` module to hold the different mutually recursive functions together. Just a move, no code change. The following commits attempt to make the logic a bit more readable. The two fields `last_import_segment` and `unusable_binding` are replaced by function parameters. In order to manage the fallout, `maybe_` variants of the function are added, dedicated to speculative resolution. r? `@petrochenkov`
Implement tuples using recursion Because it is c00l3r™, requires less repetition and can be used as a reference for external people. This change is non-essential and I am not sure about potential performance impacts so feel free to close this PR if desired. r? `@petrochenkov`
…llot Delay a bug when we see SelfCtor in ref pattern Fixes rust-lang#95878
…s, r=compiler-errors
Fix suggestions in case of `T:` bounds
This PR fixes a corner case in `suggest_constraining_type_params` that was causing incorrect suggestions.
For the following functions:
```rust
fn a<T:>(t: T) { [t, t]; }
fn b<T>(t: T) where T: { [t, t]; }
```
We previously suggested the following:
```text
...
help: consider restricting type parameter `T`
|
1 | fn a<T: Copy:>(t: T) { [t, t]; }
| ++++++
...
help: consider further restricting this bound
|
2 | fn b<T>(t: T) where T: + Copy { [t, t]; }
| ++++++
```
Note that neither `T: Copy:` not `where T: + Copy` is a correct bound.
With this commit the suggestions are correct:
```text
...
help: consider restricting type parameter `T`
|
1 | fn a<T: Copy>(t: T) { [t, t]; }
| ++++
...
help: consider further restricting this bound
|
2 | fn b<T>(t: T) where T: Copy { [t, t]; }
| ++++
```
r? `@compiler-errors`
I've tried fixing rust-lang#95898 here too, but got too confused with how `suggest_traits_to_import` works and what it does 😅
prevent opaque types from appearing in impl headers cc `@lqd` opaque types are not distinguishable from their hidden type at the codegen stage. So we could either end up with cases where the hidden type doesn't implement the trait (which will thus ICE) or where the hidden type does implement the trait (so we'd be using its impl instead of the one written for the opaque type). This can even lead to unsound behaviour without unsafe code. Fixes rust-lang#86411. Fixes rust-lang#84660. rebase of rust-lang#87382 plus some diagnostic tweaks
…crum Autolabel library PRs with T-libs Continuation of rust-lang/highfive#389 We're trying to improve the libs team review structure and part of that is defaulting PRs to the T-libs team to act as a mini-triage team for all the libs teams / project groups. Highfive doesn't do issue tagging so we will rely on triagebot to pre-triage for t-libs to post-triage :)
|
📌 Commit bdbc398 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit bdbc398 with merge 8d2a6b0d0362e5405977dd4d5787da30177452b0... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☀️ Test successful - checks-actions |
This was referenced Apr 13, 2022
|
Finished benchmarking commit (1491e5c): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
|
Visiting for weekly performance triage. This PR regressed diesel doc by 4.1%, and associated-items doc by 71% (!). Seems important. Left comment on PR #95316 asking for further investigation. (I'm not adding the -triaged label, at least not until after we see results of further investigation, or someone justifies the regression as worth it in order to reap associated benefits of the PR injecting the regression...) |
|
The regression is indeed caused by my PR #95316 since rustdoc now evaluates and prints the default value of provided associated constants. Const evaluation is the culprit here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
T:bounds #95970 (Fix suggestions in case ofT:bounds)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup