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 5 pull requests #101195

Merged
merged 14 commits into from
Aug 30, 2022
Merged

Rollup of 5 pull requests #101195

merged 14 commits into from
Aug 30, 2022

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

compiler-errors and others added 14 commits July 30, 2022 00:41
Now that we require at least LLVM 13, that codegen backend is always
using its intrinsic `fptosi.sat` and `fptoui.sat` conversions, so it
doesn't need the manual implementation. However, the GCC backend still
needs it, so we can move all of that code down there.
The `*-ptr` is rather confusing, and we have the full information for
properly displaying the information.
…rpolation

	modified:   compiler/rustc_passes/src/liveness.rs

	new file:   src/test/ui/type/issue-100584.rs
	new file:   src/test/ui/type/issue-100584.stderr
…er-errors

Display raw pointer as *{mut,const} T instead of *-ptr in errors

The `*-ptr` is rather confusing, and we have the full information for properly displaying the information.
Do not leak type variables from opaque type relation

The "root cause" is that we call `InferCtxt::resolve_vars_if_possible` (3d9dd68) on the types we get back in `TypeError::Sorts` since I added a call to it in `InferCtxt::same_type_modulo_infer`. However if this `TypeError` comes from a `InferCtxt::commit_if_ok`, then it may reference type variables that do not exist anymore, which is problematic.

We avoid this by substituting the `TypeError` with the types we had before being generalized while handling opaques.

This is kinda gross, and I feel like we can get the same issue from other places where we generalize type/const inference variables. Maybe not? I don't know.

Fixes rust-lang#99914
Fixes rust-lang#99970
Fixes rust-lang#100463
…ef-sig-plz, r=lcnr

Attempt to normalize `FnDef` signature in `InferCtxt::cmp`

Stashes a normalization callback in `InferCtxt` so that the signature we get from `tcx.fn_sig(..).subst(..)` in `InferCtxt::cmp` can be properly normalized, since we cannot expect for it to have normalized types since it comes straight from astconv.

This is kind of a hack, but I will say that `@jyn514` found the fact that we present unnormalized types to be very confusing in real life code, and I agree with that feeling. Though altogether I am still a bit unsure about whether this PR is worth the effort, so I'm open to alternatives and/or just closing it outright.

On the other hand, this isn't a ridiculously heavy implementation anyways -- it's less than a hundred lines of changes, and half of that is just miscellaneous cleanup.

This is stacked onto rust-lang#100471 which is basically unrelated, and it can be rebased off of that when that lands or if needed.

---

The code:
```rust
trait Foo { type Bar; }

impl<T> Foo for T {
    type Bar = i32;
}

fn foo<T>(_: <T as Foo>::Bar) {}

fn needs_i32_ref_fn(f: fn(&'static i32)) {}

fn main() {
    needs_i32_ref_fn(foo::<()>);
}
```

Before:
```
   = note: expected fn pointer `fn(&'static i32)`
                 found fn item `fn(<() as Foo>::Bar) {foo::<()>}`
```

After:
```
   = note: expected fn pointer `fn(&'static i32)`
                 found fn item `fn(i32) {foo::<()>}`
```
…ister,antoyo

Move the cast_float_to_int fallback code to GCC

Now that we require at least LLVM 13, that codegen backend is always
using its intrinsic `fptosi.sat` and `fptoui.sat` conversions, so it
doesn't need the manual implementation. However, the GCC backend still
needs it, so we can move all of that code down there.
Point at the string inside literal and mention if we need string inte…

…rpolation

	modified:   compiler/rustc_passes/src/liveness.rs
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Aug 30, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Aug 30, 2022

📌 Commit 467d2c1 has been approved by Dylan-DPC

It is now in the queue for this repository.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 30, 2022
@bors
Copy link
Contributor

bors commented Aug 30, 2022

⌛ Testing commit 467d2c1 with merge fce6a7d...

@bors
Copy link
Contributor

bors commented Aug 30, 2022

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing fce6a7d to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 30, 2022
@bors bors merged commit fce6a7d into rust-lang:master Aug 30, 2022
@rustbot rustbot added this to the 1.65.0 milestone Aug 30, 2022
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#100941 68f69c7a45e0d72dd56f911f7165b045fc996309
#100653 b7892b4ebffdde131d4183e2241d23b2767f8a7f
#100473 5e978c58279ee22c044aff2c561f36c2411663c6
#99928 8222e2c141192edd1249e1f82668f5d0df7be2b6
#99517 b329492d13ab934ee371d34309166262a20d48ef

previous master: 230a8ee364

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 (fce6a7d): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

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.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.2% [-2.3%, -2.1%] 2
All ❌✅ (primary) - - 0

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.

mean1 range count2
Regressions ❌
(primary)
2.3% [2.3%, 2.3%] 1
Regressions ❌
(secondary)
3.9% [3.7%, 4.1%] 2
Improvements ✅
(primary)
-2.6% [-2.6%, -2.6%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.2% [-2.6%, 2.3%] 2

Footnotes

  1. the arithmetic mean of the percent change 2

  2. number of relevant changes 2

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants