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

Closed
wants to merge 44 commits into from

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

xFrednet and others added 30 commits March 29, 2022 00:42
This ICE was reported by `@matthiaskrgr`. A big THANK YOU to him. See `rust#94953`
Co-authored-by: Philipp Krones <[email protected]>
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"
Also rename the test files for the unused_macros lint to avoid confusion.
The test files now follow a <lint_name><-maybe-decl>.rs scheme.
Looks like they were in FxHash order before, so it might just be luck that this used to be consistent across different word lengths.
Port the "unconstrained opaque type" diagnostic to using the diagnostic
derive.

Signed-off-by: David Wood <[email protected]>
Diagnostics can have multiple primary spans, or have subdiagnostics
repeated at multiple locations, so support `Vec<..>` fields in the
diagnostic derive which become loops in the generated code.

Signed-off-by: David Wood <[email protected]>
Currently, the only API for creating errors from a diagnostic derive
will emit it immediately. This makes it difficult to add subdiagnostics
to diagnostics from the derive, so add `create_{err,warning}` functions
that return the diagnostic without emitting it.

Signed-off-by: David Wood <[email protected]>
Port the "explicit generic arguments with impl trait" diagnostic to
using the diagnostic derive.

Signed-off-by: David Wood <[email protected]>
RalfJung and others added 14 commits May 6, 2022 10:58
…esleywiser

Support tool lints with the `#[expect]` attribute (RFC 2383)

This PR fixes the ICE rust-lang#94953 by making the assert for converted expectation IDs conditional.

Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.

The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. 🦕

---

Closes: rust-lang#94953

cc: rust-lang#85549

r? ``@wesleywiser``

cc: ``@rust-lang/rustdoc``
…enkov

Implement a lint to warn about unused macro rules

This implements a new lint to warn about unused macro rules (arms/matchers), similar to the `unused_macros` lint added by rust-lang#41907 that warns about entire macros.

```rust
macro_rules! unused_empty {
    (hello) => { println!("Hello, world!") };
    () => { println!("empty") }; //~ ERROR: 1st rule of macro `unused_empty` is never used
}

fn main() {
    unused_empty!(hello);
}
```

Builds upon rust-lang#96149 and rust-lang#96156.

Fixes rust-lang#73576
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
make Size and Align debug-printing a bit more compact

In particular in `{:#?}`-mode, these take up a lot of space, so I think this is the better alternative (even though it is a bit longer in `{:?}` mode, I think it is still more readable).

We could make it even smaller by deviating further from what the actual code looks like, e.g. via something like `Size(4 bytes)`. Not sure what people would think about that?

Cc ``@oli-obk``
…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)
…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.
…c, r=oli-obk

diagnostics: port more diagnostics to derive + add support for `Vec` fields

- Port "unconstrained opaque type" diagnostic to using the derive.
- Allow `Vec` fields in diagnostic derive - enables support for diagnostics that have multiple primary spans, or have subdiagnostics repeated at multiple locations. `Vec<..>` fields in the diagnostic derive become loops in the generated code.
- Add `create_{err,warning}` - there wasn't a way to create a diagnostic from a struct and not emit it straight away.
- Port "explicit generic args w/ impl trait" diagnostic to using the derive.

r? ``@oli-obk``
cc ``@pvdrz``
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library 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+ rollup=never p=10

@bors
Copy link
Contributor

bors commented May 6, 2022

📌 Commit 9e1fcaf 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 9e1fcaf with merge 17696a62295df34fd4a02bc6bb1812cfeae19a26...

@bors
Copy link
Contributor

bors commented May 6, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 6, 2022
@rust-log-analyzer
Copy link
Collaborator

The job dist-powerpc64-linux failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
   Compiling compiler_builtins v0.1.71
   Compiling unwind v0.0.0 (/checkout/library/unwind)
[RUSTC-TIMING] build_script_build test:false 0.312
[RUSTC-TIMING] build_script_build test:false 0.511
error: 1st rule of macro `simd_shuffle2` is never used
   |
   |
98 |     ($x:expr, $y:expr, <$(const $imm:ident : $ty:ty),+ $(,)?> $idx:expr $(,)?) => {{
   |
   |
   = note: `-D unused-macro-rules` implied by `-D warnings`

error: 3rd rule of macro `impl_vec_trait` is never used
   --> library/core/src/../../stdarch/crates/core_arch/src/powerpc/altivec.rs:379:9
    |
379 |         ([$Trait:ident $m:ident] 1 ($ub:ident, $sb:ident, $uh:ident, $sh:ident, $uw:ident, $sw:ident, $sf: ident)) => {


error: 9th rule of macro `impl_vec_trait` is never used
   --> library/core/src/../../stdarch/crates/core_arch/src/powerpc/altivec.rs:422:9
    |
422 |         ([$Trait:ident $m:ident] 2 ($fn:ident)) => {

[RUSTC-TIMING] core test:false 11.298
error: could not compile `core` due to 3 previous errors
Build completed unsuccessfully in 0:05:07

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup 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-libs Relevant to the library 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.