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

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
Contributor

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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