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

Merged
merged 31 commits into from
May 6, 2022
Merged

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

tmiasko and others added 30 commits May 3, 2022 07:12
The constants used in SymFn operands have FnDef type,
so the type of the constant identifies the function.
The generic arg is for type inference only and shouldn't be exposed
to users.
* If it's just `-> a`, use "In Function Return Types"
* If it's just `a b`, use "In Function Parameters"
* Otherwise, still use "In Function Signatures"
Looks like they were in FxHash order before, so it might just be luck that this used to be consistent across different word lengths.
Allow inline consts to reference generic params

Tracking issue: rust-lang#76001

The RFC says that inline consts cannot reference to generic parameters (for now), same as array length expressions. And expresses that it's desirable for it to reference in-scope generics, when array length expressions gain that feature as well.

However it is possible to implement this for inline consts before doing this for all anon consts, because inline consts are only used as values and they won't be used in the type system. So we can have:
```rust
fn foo<T>() {
    let x = [4i32; std::mem::size_of::<T>()];   // NOT ALLOWED (for now)
    let x = const { std::mem::size_of::<T>() }; // ALLOWED with this PR!
    let x = [4i32; const { std::mem::size_of::<T>() }];   // NOT ALLOWED (for now)
}
```

This would make inline consts super useful for compile-time checks and assertions:
```rust
fn assert_zst<T>() {
    const { assert!(std::mem::size_of::<T>() == 0) };
}
```

This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary, but this is exactly what a "desugared" inline const would do:
```rust
fn assert_zst<T>() {
    struct F<T>(T);
    impl<T> F<T> {
        const V: () = assert!(std::mem::size_of::<T>() == 0);
    }
    let _ = F::<T>::V;
}
```

It should also be noted that the current inline const implementation can already reference the type params via type inference, so this resolver-level restriction is not any useful either:
```rust
fn foo<T>() -> usize {
    let (_, size): (PhantomData<T>, usize) = const {
        const fn my_size_of<T>() -> (PhantomData<T>, usize) {
            (PhantomData, std::mem::size_of::<T>())
        }
        my_size_of()
    };
    size
}
```

```@rustbot``` label: F-inline_const
…ch, r=GuillaumeGomez,jsha

rustdoc: when running a function-signature search, tweak the tab bar

# Before

![In Names (7) / In Parameters (0) / In Return types (0)](https://user-images.githubusercontent.com/1593513/166122875-ffdeafe6-8d4d-4e61-84a6-f5986b50ac35.png)

# After

![In Function Signature (7)](https://user-images.githubusercontent.com/1593513/166122883-9a3d7515-3235-4ee3-8c4b-5401d109e099.png)
Collect function instance used in `global_asm!` sym operand

The constants used in SymFn operands have FnDef type,
so the type of the constant identifies the function.

Fixes rust-lang#96623.
…twco

turn `append_place_to_string` from recursion into iteration

This PR fixes the FIXME in the impl of `append_place_to_string` which turns `append_place_to_string` from recursion into iteration, meanwhile simplifying the code relatively.
… r=notriddle

Fixes reexports in search

Fixes rust-lang#96681.

At some point we stopped reexporting items in search so this PR fixes it.

It also adds a regression test.

r? ```@notriddle```
…errors

Put the incompatible_closure_captures lint messages in alphabetical order

Looks like they were in hash order before, which was causing me trouble in rust-lang#94598, so this PR sorts the errors by trait name.
…h-with-appropriate-params, r=compiler-errors

Suggest fully qualified path with appropriate params

closes rust-lang#96291
Fix two minor issues in hir.rs

I found these two places in hir.rs which could use a bit of improvements while going through the code.

No functional change.
@rustbot rustbot added 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, 2022
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=10 rollup=never

@bors
Copy link
Contributor

bors commented May 6, 2022

📌 Commit a0e2c7e has been approved by GuillaumeGomez

@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 May 6, 2022
@bors
Copy link
Contributor

bors commented May 6, 2022

⌛ Testing commit a0e2c7e with merge 77652b9...

@bors
Copy link
Contributor

bors commented May 6, 2022

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing 77652b9 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 6, 2022
@bors bors merged commit 77652b9 into rust-lang:master May 6, 2022
@rustbot rustbot added this to the 1.62.0 milestone May 6, 2022
@GuillaumeGomez GuillaumeGomez deleted the rollup-rgiwa57 branch May 6, 2022 22:44
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (77652b9): comparison url.

Summary:

  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: 😿 relevant regression found
Regressions 😿
(primary)
Regressions 😿
(secondary)
Improvements 🎉
(primary)
Improvements 🎉
(secondary)
All 😿 🎉
(primary)
count1 0 1 0 0 0
mean2 N/A 0.2% N/A N/A N/A
max N/A 0.2% N/A N/A N/A

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. number of relevant changes

  2. the arithmetic mean of the percent change

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.