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

Closed
wants to merge 31 commits into from
Closed

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

clubby789 and others added 30 commits January 4, 2023 15:54
Co-authored-by: lcnr <rust@lcnr.de>
Keep ids of the documented items themselves, not their parent modules.
Parent modules can be retreived from those ids when necessary.
…he8472

Document `Iterator::sum/product` for Option/Result

Closes rust-lang#105266

We already document the similar behavior for `collect()` so I believe it makes sense to add this too. The Option/Result implementations *are* documented on their respective pages and the page for `Sum`, but buried amongst many other trait impls which doesn't make it very discoverable.

`@rustbot` label +A-docs
Lint ambiguous glob re-exports

Attempts to fix rust-lang#107563.

We currently already emit errors for ambiguous re-exports when two names are re-exported *specifically*, i.e. not from glob exports. This PR attempts to emit deny-by-default lints for ambiguous glob re-exports.
…r=oli-obk

Suppress `opaque_hidden_inferred_bound` for nested RPITs

They trigger too much, making repos like linkerd/linkerd2-proxy#2275 sad.

Ideally, at least for RPITs (and probably TAITs?), specifically when we have `impl Trait<Assoc = impl ..>`, that nested opaque should have the necessary `Assoc` item bounds elaborated into its own item bounds. But that's another story.

r? `@oli-obk`
…rs-object-safe, r=b-naber

Enforce non-lifetime-binders in supertrait preds are not object safe

We can't construct vtables for these supertraits.
…lcnr

new solver: make all goal evaluation able to be automatically rerun

It is generally wrong to call `evaluate_goal` multiple times or `evaluate_goal` and `evaluate_all` for the same `QueryResult` without correctly handling rerunning the goals when inference makes progress. Not doing so will result in the assertion in `evaluate_goal` firing because rerunning the goal will lead to a more accurate `QueryResult`.

Currently there are lots of places that get this wrong and generally it is complex and error prone to handle correctly everywhere. This PR introduces a way to add goals to the `EvalCtxt` and then run all the added goals in a loop so that `evaluate_goal`/`evaluate_all` is not necessary to call manually.

There are a few complications for making everything work "right":
1. the `normalizes-to` hack that replaces the rhs with an unconstrained infer var requires special casing in the new `try_evaluate_added_goals` function similar to how `evaluate_goal`'s assertion special cases that hack.

2. `assemble_candidates_after_normalizing_self_ty`'s normalization step needs to be reran for each candidate otherwise the found candidates will potentially get a more accurate `QueryResult` when rerunning the projection/trait goal which can effect the `QueryResult` of the projection/trait goal.
This is implemented via `EvalCtxt::probe`'s closure's `EvalCtxt` inheriting the added goals of the `EvalCtxt` that `probe` is called on, allowing us to add goals in a probe, and then enter a nested probe for each candidate and evaluate added goals which include the normalization step's goals.

I made `make_canonical_response` evaluate added goals so that it will be hard to mess up the impl of the solver by forgetting to evaluate added goals. Right now the only way to mess this up would be to call `response_no_constraints` (which from the name is obviously weird).

The visibility of `evaluate_goal` means that it can be called from various `compute_x_goal` or candidate assembly functions, this is generally wrong and we should never call `evaluate_goal` manually, instead we should be calling `add_goal`/`add_goals`. This is solved by moving `evaluate_goal` `evaluate_canonical_goal` and `compute_goal` into `eval_ctxt`'s module and making them private so they cannot be called from elsewhere, forcing people to call `add_goal/s` and `evaluate_added_goals_and_make_canonical_resposne`/`try_evaluate_added_goals`

---

Other changes:
- removed the `&& false` that was introduced to the assertion in `evaluate_goal` in rust-lang#108839
- remove a `!self.did_overflow()` requirement in `search_graph.is_empty()` which causes goals that overflow to ICE
- made `EvalCtxt::eq` take `&mut self` and add all the nested goals via `add_goals` instead of returning them as 99% of call sites just immediately called `EvalCtxt::add_goals` manually.

r? `@lcnr`
…ce, r=eholk

move Option::as_slice to intrinsic

`@scottmcm` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation.

cc `@nikic` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
… r=oli-obk

Walk un-shifted nested `impl Trait` in trait when setting up default trait method assumptions

Fixes a double subtraction in some binder math in return-position `impl Trait` in trait handling code.

Fixes rust-lang#109239
…omez

rustdoc: Cleanup parent module tracking for doc links

Keep ids of the documented items themselves, not their parent modules. Parent modules can be retreived from those ids when necessary.

Fixes rust-lang#108501.
That issue could be fixed in a more local way, but this refactoring is something that I wanted to do since rust-lang#93805 anyway.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative rollup A PR which is a rollup labels Mar 21, 2023
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Mar 21, 2023

📌 Commit a5442d2 has been approved by Dylan-DPC

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 21, 2023
@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 rustc_passes v0.0.0 (/checkout/compiler/rustc_passes)
error[E0432]: unresolved import `rustc_middle::ty::DefIdTree`
 --> compiler/rustc_lint/src/opaque_hidden_inferred_bound.rs:5:72
  |
5 |     self, fold::BottomUpFolder, print::TraitPredPrintModifiersAndPath, DefIdTree, Ty, TypeFoldable,
  |                                                                        ^^^^^^^^^ no `DefIdTree` in `ty`
For more information about this error, try `rustc --explain E0432`.
error: could not compile `rustc_lint` due to previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `rustc_lint` due to previous error

@matthiaskrgr
Copy link
Member

@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 Mar 21, 2023
@Nilstrieb
Copy link
Member

This includes #108541 which is broken, so I'll close it

@Nilstrieb Nilstrieb closed this Mar 21, 2023
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet