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 9 pull requests #109130

Merged
merged 23 commits into from
Mar 14, 2023
Merged

Rollup of 9 pull requests #109130

merged 23 commits into from
Mar 14, 2023

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

petrhosek and others added 23 commits March 4, 2023 20:50
Fuchsia is in the process of implementing the RISC-V support. This
change implements the minimal Rust compiler support. The support for
building runtime libraries will be implemented in follow up changes
once Fuchsia SDK has the RISC-V support.
If no method is found when checking method call, we check  if we called a method with signature (&mut T, ...) -> (). If this is the case then we emit a diagnostic message
…enkov

Support for Fuchsia RISC-V target

Fuchsia is in the process of implementing the RISC-V support. This change implements the minimal Rust compiler support. The support for building runtime libraries will be implemented in follow up changes once Fuchsia SDK has the RISC-V support.
…r-errors

Remove tests/ui/impl-trait/in-trait/new-lowering-strategy in favor of using revisions on existing tests

r? `@compiler-errors`

This one again sits on top of existing approved PRs and it still needs to add revisions to tests in `tests/ui/impl-trait/in-trait` as it only does so for async in traits.
…r-errors

Fix object safety checks for new RPITITs

This one goes on top of rust-lang#108869

r? `@compiler-errors`
…r-errors

Remove some direct calls to local_def_id_to_hir_id on diagnostics

Was playing with `tests/ui/impl-trait/in-trait/default-body-with-rpit.rs` and was able to remove some ICEs. Still getting ...

```
error[E0277]: `impl Future<Output = Foo::{opaque#0}>` is not a future
  --> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:28
   |
10 |     async fn baz(&self) -> impl Debug {
   |                            ^^^^^^^^^^ `impl Future<Output = Foo::{opaque#0}>` is not a future
   |
   = help: the trait `Future` is not implemented for `impl Future<Output = Foo::{opaque#0}>`
   = note: impl Future<Output = Foo::{opaque#0}> must be a future or must implement `IntoFuture` to be awaited
note: required by a bound in `Foo::{opaque#1}`
  --> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:28
   |
10 |     async fn baz(&self) -> impl Debug {
   |                            ^^^^^^^^^^ required by this bound in `Foo::{opaque#1}`

error[E0277]: the size for values of type `impl Future<Output = Foo::{opaque#0}>` cannot be known at compilation time
  --> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:28
   |
10 |     async fn baz(&self) -> impl Debug {
   |                            ^^^^^^^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `Sized` is not implemented for `impl Future<Output = Foo::{opaque#0}>`
note: required by a bound in `Foo::{opaque#1}`
  --> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:28
   |
10 |     async fn baz(&self) -> impl Debug {
   |                            ^^^^^^^^^^ required by this bound in `Foo::{opaque#1}`

error: internal compiler error: compiler/rustc_hir_typeck/src/closure.rs:724:18: async fn generator return type not an inference variable: Foo::{opaque#1}<'_>
  --> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:39
   |
10 |       async fn baz(&self) -> impl Debug {
   |  _______________________________________^
11 | |         ""
12 | |     }
   | |_____^
```

But I guess this is a little bit of progress anyway.

This one goes on top of rust-lang#108700 and rust-lang#108945
r? `@compiler-errors`
…r-errors

Make fns from other crates with RPITIT work for -Zlower-impl-trait-in-trait-to-assoc-ty

Only the last two commits are meaningful.

r? `@compiler-errors`
…aelwoerister

Fall back to old metadata computation when type references errors

Projection is a bit too aggressive normalizing `<dyn Trait<[type error]> as Pointee>::Metadata` to `[type error]`, rather than to `DynMetadata<..>`. Side-step that by just falling back to the old structural metadata computation.

Fixes rust-lang#109078
…, r=oli-obk

Don't ICE for late-bound consts across `AnonConstBoundary`

Fixes rust-lang#108194
…no, r=jackh726

Don't codegen impossible to satisfy impls

Fixes rust-lang#109098
…agn-when-method-not-found, r=petrochenkov

Emit diagnostic when calling methods on the unit type in method chains

Fixes rust-lang#104204.

What this PR does: If a method is not found somewhere in a call chain, we check if we called earlier a method with signature `(&mut T, ...) -> ()`. If this is the case then we emit a diagnostic message.

For example given input:

```
vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort();
```

the current output is:
```
error[E0599]: no method named `sort` found for unit type `()` in the current scope
 --> hello.rs:3:72
  |
3 |     vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort();
  |                                                                        ^^^^ method not found in `()`

```

after this PR it will be:
```
error[E0599]: no method named `sort` found for unit type `()` in the current scope
 --> ./hello.rs:3:72
  |
3 |     vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort();
  |                                                                        ^^^^ method not found in `()`
  |

note: method `sort_by_key` modifies its receiver in-place, it is not meant to be used in method chains.
 --> ./hello.rs:3:53
  |
3 |     vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort();
  |                                                     ^^^^^^^^^^^ this call modifies its receiver in-place
```
@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. rollup A PR which is a rollup labels Mar 14, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=9

@bors
Copy link
Contributor

bors commented Mar 14, 2023

📌 Commit b17ee10 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 Mar 14, 2023
@bors
Copy link
Contributor

bors commented Mar 14, 2023

⌛ Testing commit b17ee10 with merge 1716932...

@bors
Copy link
Contributor

bors commented Mar 14, 2023

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 14, 2023
@bors bors merged commit 1716932 into rust-lang:master Mar 14, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 14, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1716932): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.3% [0.3%, 0.4%] 6
Regressions ❌
(secondary)
0.6% [0.3%, 1.0%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.5% [-0.5%, -0.3%] 5
All ❌✅ (primary) 0.3% [0.3%, 0.4%] 6

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.9% [3.9%, 3.9%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

@rustbot rustbot added the perf-regression Performance regression. label Mar 15, 2023
@pnkfelix
Copy link
Member

  • the primary regressions are all to stm32f4-0.14.0 incremental (unchanged and patched:negate).
  • nothing in the rollup stands out as an obvious culprit. (I was briefly curious about Fall back to old metadata computation when type references errors #109101, but I think that indeed should only affect compilation of type-erroneous code, IIUC)
  • marking as triaged, because I do not think these results warrant deeper investigation at this time.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Mar 21, 2023
@matthiaskrgr matthiaskrgr deleted the rollup-dm3jza6 branch March 16, 2024 18:19
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. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants