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 7 pull requests #111287

Merged
merged 19 commits into from
May 6, 2023
Merged

Rollup of 7 pull requests #111287

merged 19 commits into from
May 6, 2023

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jyn514 and others added 19 commits April 29, 2023 06:39
This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.

- Switch clippy to the new hook

  This also adds a `extra_info` callback so clippy can include its own version number, which differs
  from rustc's.

- Call `install_ice_hook` in rustfmt
When we're adding a method to a type DIE, we only want a DW_AT_declaration
there, because LLVM LTO can't unify type definitions when a child DIE is a
full subprogram definition. Now the subprogram definition gets added at the
CU level with a specification link back to the abstract declaration.
Previously, incorrect spans were reported if inline assembly contained
CRLF (Windows) line endings.

Fixes rust-lang#110885
… r=lcnr

Use fulfillment to check `Drop` impl compatibility

Use an `ObligationCtxt` to ensure that a `Drop` impl does not have stricter requirements than the ADT that it's implemented for, rather than using a `SimpleEqRelation` to (more or less) syntactically equate predicates on an ADT with predicates on an impl.

r? types

### Some background

The old code reads:

```rust
// An earlier version of this code attempted to do this checking
// via the traits::fulfill machinery. However, it ran into trouble
// since the fulfill machinery merely turns outlives-predicates
// 'a:'b and T:'b into region inference constraints. It is simpler
// just to look for all the predicates directly.
```

I'm not sure what this means, but perhaps in the 8 years since that this comment was written (cc rust-lang#23638) it's gotten easier to process region constraints after doing fulfillment? I don't know how this logic differs from anything we do in the `compare_impl_item` module. Ironically, later on it says:

```rust
// However, it may be more efficient in the future to batch
// the analysis together via the fulfill (see comment above regarding
// the usage of the fulfill machinery), rather than the
// repeated `.iter().any(..)` calls.
```

Also:
* Removes `SimpleEqRelation` which was far too syntactical in its relation.
* Fixes rust-lang#110557
Add Terminator conversion from MIR to SMIR, part #1

This adds internal MIR TerminatorKind to SMIR Terminator conversion.

r? ```@oli-obk```
…aber

Fix spans in LLVM-generated inline asm errors

Previously, incorrect spans were reported if inline assembly contained CRLF (Windows) line endings.

Fixes rust-lang#110885
Make the BUG_REPORT_URL configurable by tools

This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.

I haven't changed clippy in case they want to make the change upstream instead of the subtree, but
I'm happy to do so here if the maintainers want - cc ````@rust-lang/clippy````

Fixes rust-lang#109486.
…michaelwoerister

debuginfo: split method declaration and definition

When we're adding a method to a type DIE, we only want a DW_AT_declaration
there, because LLVM LTO can't unify type definitions when a child DIE is a
full subprogram definition. Now the subprogram definition gets added at the
CU level with a specification link back to the abstract declaration.

Both GCC and Clang write debuginfo this way for C++ class methods.

Fixes rust-lang#109730.
Fixes rust-lang#109934.
…mpiler-errors

add hint for =< as <=

Adds a compiler hint for when `=<` is typed instead of `<=`

Example hint:
```rust
fn foo() {
    if 1 =< 3 {
        println!("Hello, World!");
    }
}
```
```
error: expected type, found `3`
 --> main.rs:2:13
  |
2 |     if 1 =< 3 {
  |          -- ^ expected type
  |          |
  |          help: did you mean: `<=`
```

This PR only emits the suggestion if there is no space between the `=` and `<`.  This hopefully narrows the scope of when this error is emitted, however this still allows this error to be emitted in cases such as this:
```
error: expected expression, found `;`
 --> main.rs:2:18
  |
2 |     if 1 =< [i32;; 3]>::hello() {
  |          --      ^ expected expression
  |          |
  |          help: did you mean: `<=`
```

Which could be a good reason not to merge since I haven't been able to think of any other ways of narrowing the scope of this diagnostic.

closes rust-lang#111128
… r=cjgillot

More robust debug assertions for `Instance::resolve` on built-in traits with non-standard trait items

In rust-lang#111264, a user added a new item to the `Future` trait, but the code in [`resolve_associated_item`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ty_utils/instance/fn.resolve_associated_item.html) implicitly assumes that the `Future` trait is defined with only one method (`Future::poll`) and treats the generator body as the implementation of that method.

This PR adds some debug assertions to make sure that that new methods defined on `Future`/`Generator`/etc. don't accidentally resolve to the wrong item when they are added, and adds a helpful comment guiding a compiler dev (or curious `#![no_core]` user) to what must be done to support adding new associated items to these built-in implementations.

I am open to discuss whether a test should be added, but I chose against it because I opted to make these `bug!()`s instead of, e.g., diagnostics or fatal errors. Arguably it doesn't need a test because it's not a bug that can be triggered by an end user, and internal-facing misuses of core kind of touch on rust-lang/compiler-team#620 -- however, I think the assertions I added in this PR are still a very useful way to make sure this bug doesn't waste debugging resources down the line.

Fixes rust-lang#111264
@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-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels May 6, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented May 6, 2023

📌 Commit 3cb1a46 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 May 6, 2023
@bors
Copy link
Contributor

bors commented May 6, 2023

⌛ Testing commit 3cb1a46 with merge 905d5a3...

@bors
Copy link
Contributor

bors commented May 6, 2023

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 6, 2023
@bors bors merged commit 905d5a3 into rust-lang:master May 6, 2023
@rustbot rustbot added this to the 1.71.0 milestone May 6, 2023
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#111279 58e461c00e60d8cd7629c31984369e275f15f9de
#111230 87bc055df541af93a809e3c7db6d4efeaa833178
#111167 429ea1de32a5ca6b68b137f8256d9dbe4dada1c5
#110989 c7c72eabd78144db78a9f0cd4609a69c5474292c
#110985 99c42d2e58d7370a90d369c5f7d002506ee07c9f
#110610 c30facb39f1596dbd80c4c4334993c3bdd5965e7
#110577 2fea21ede2fad177f0a1af21eef94f2755fc1a58

previous master: 333b920fee

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (905d5a3): comparison URL.

Overall result: ❌ regressions - 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)
1.9% [1.0%, 3.0%] 4
Regressions ❌
(secondary)
5.6% [0.2%, 8.2%] 7
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.9% [1.0%, 3.0%] 4

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.3% [0.3%, 0.3%] 1
Regressions ❌
(secondary)
3.7% [2.9%, 4.6%] 2
Improvements ✅
(primary)
-7.8% [-7.8%, -7.8%] 1
Improvements ✅
(secondary)
-1.8% [-3.3%, -1.1%] 3
All ❌✅ (primary) -3.7% [-7.8%, 0.3%] 2

Cycles

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)
1.4% [1.4%, 1.4%] 1
Regressions ❌
(secondary)
4.9% [3.8%, 6.1%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.8% [-2.8%, -2.8%] 1
All ❌✅ (primary) 1.4% [1.4%, 1.4%] 1

Binary size

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.4% [0.0%, 1.1%] 80
Regressions ❌
(secondary)
0.2% [0.0%, 0.3%] 14
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.3% [-0.5%, -0.3%] 4
All ❌✅ (primary) 0.4% [0.0%, 1.1%] 80

Bootstrap: 656.005s -> 653.763s (-0.34%)

@rustbot rustbot added the perf-regression Performance regression. label May 6, 2023
@Mark-Simulacrum
Copy link
Member

This is our standard bimodality kicking in on the affected benchmarks, dropping regression label.

@Mark-Simulacrum Mark-Simulacrum removed the perf-regression Performance regression. label May 16, 2023
@matthiaskrgr matthiaskrgr deleted the rollup-9lzax2c branch March 16, 2024 18:18
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. 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-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.