Skip to content

Rollup of 10 pull requests #105720

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 29 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ComputerDruid and others added 29 commits December 8, 2022 10:58
As a workaround for the full `#[refine]` semantics not being implemented
yet, forbit returning a concrete future type like `Box<dyn Future>` or a
manually implemented Future.

`-> impl Future` is still permitted; while that can also cause
accidental refinement, that's behind a different feature gate
(`return_position_impl_trait_in_trait`) and that problem exists
regardless of whether the trait method is async, so will have to be
solved more generally.

Fixes rust-lang#102745
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
When `with_forced_trimmed_paths` is used, only print filename and start
of the closure's span, to reduce their verbosity.
Do not say "Type changed to X here" when the only difference is caused
by lifetimes.
It takes less time to run than the other tests and is more likely to fail.
`expand-yaml-anchors` is still run first to make sure the CI files are internally consistent.
This takes a long time and rarely fails. It also interferes with `retry make prepare`, the retry is unhelpful since `make prepare` turns into a no-op
…f-id, r=estebank

Use impl's def id when calculating type to specify in UFCS

Fixes rust-lang#104327
Fixes rust-lang#104328

Also addresses rust-lang#102670 (comment)
…ler-errors

Ensure async trait impls are async (or otherwise return an opaque type)

As a workaround for the full `#[refine]` semantics not being implemented
yet, forbit returning a concrete future type like `Box<dyn Future>` or a
manually implemented Future.

`-> impl Future` is still permitted; while that can also cause
accidental refinement, that's behind a different feature gate
(`return_position_impl_trait_in_trait`) and that problem exists
regardless of whether the trait method is async, so will have to be
solved more generally.

Fixes rust-lang#102745
…env-2, r=estebank

Highlight conflicting param-env candidates, again

Un-reverts rust-lang#98794 (i.e. reverts rust-lang#99290).

The previous time I attempted to land this PR, it was because of an incremental issue (rust-lang#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by `@lcnr)` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly.

The main motivation for trying to re-land this is that it fixes rust-lang#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates:

```
error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>`
   |
note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found
  --> $DIR/conflicting-bounds.rs:3:1
   |
LL | pub trait Gen<'source> {
   | ^^^^^^^^^^^^^^^^^^^^^^
...
LL |         Self: for<'s> Gen<'s, Output = T>;
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0283`.
```

Fixes rust-lang#105131.
Fixes (again) rust-lang#98786
…e-fix, r=Nilstrieb

Fix `-Z print-type-sizes` for generators with discriminant field ordered first

Fixes rust-lang#105589
Fixes rust-lang#105591
…le, r=davidtwco

Auto traits in `dyn Trait + Auto` are suggestable

Not  sure why I had made the `IsSuggestableVisitor` have that rule to not consider `dyn Trait + Auto` to be suggestable.

It's possible that this was done because of the fact that we don't print the right parentheses for `&(dyn Trait + Auto)`, but that's a problem with printing these types in general that we probably have tracked somewhere else...
…li-obk

Make `report_projection_error` more `Term` agnostic

Fixes rust-lang#105632
Point at method chains on `E0271` errors

Follow up to rust-lang#105332. Fix rust-lang#33941. CC rust-lang#9082.

r? `@oli-obk`
…-errors

Suggest constraining type parameter with `Clone`

Fix rust-lang#34896.
…-errors

Add regression test for rust-lang#104678

Closes rust-lang#104678
r? `@compiler-errors`

Signed-off-by: Yuki Okushi <jtitor@2k36.org>
Run `x test tidy` sooner in mingw-check

It takes less time to run than the other tests and is more likely to fail. `expand-yaml-anchors` is still run first to make sure the CI files are internally consistent.

Note that changing to `--stage 0` doesn't actually do anything since bootstrap tools are always built with the bootstrap compiler, this just makes it less confusing.

cc rust-lang@83bab41
@rustbot rustbot added the A-testsuite Area: The testsuite used to check the correctness of rustc label Dec 14, 2022
@rustbot rustbot added A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic 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-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 14, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Collaborator

bors commented Dec 14, 2022

📌 Commit cb19a7f has been approved by matthiaskrgr

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 Dec 14, 2022
@matthiaskrgr
Copy link
Member Author

build error in #104592

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-13 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
   Compiling rustc_hir_analysis v0.0.0 (/checkout/compiler/rustc_hir_analysis)
error[E0532]: expected tuple struct or tuple variant, found unit variant `ty::Opaque`
   --> compiler/rustc_hir_analysis/src/check/compare_method.rs:339:13
    |
339 |             ty::Opaque(..) => {
    |
   ::: /checkout/compiler/rustc_type_ir/src/sty.rs:42:5
    |
42  |     Opaque,
---
    |
1   | use rustc_infer::infer::region_constraints::GenericKind::Opaque;
    |
      and 2 other candidates
help: if you import `Opaque`, refer to it directly
    |
339 -             ty::Opaque(..) => {
339 +             Opaque(..) => {

For more information about this error, try `rustc --explain E0532`.
error: could not compile `rustc_hir_analysis` due to previous error
warning: build failed, waiting for other jobs to finish...

@matthiaskrgr matthiaskrgr deleted the rollup-78qdhzs branch December 22, 2022 10:46
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic 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-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants