-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Closed
Rollup of 10 pull requests #96775
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Not fired yet.
Co-Authored-By: Guillaume Gomez <[email protected]>
* 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.
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]>
…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.
…illaumeGomez rustdoc: ensure HTML/JS side implementors don't have dups Fixes rust-lang#94641 Rendered: - https://notriddle.com/notriddle-rustdoc-test/impl-dups/std/iter/trait.Iterator.html - https://notriddle.com/notriddle-rustdoc-test/impl-dups/core/iter/trait.Iterator.html
…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
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
@bors r+ rollup=never p=10 |
📌 Commit 9e1fcaf has been approved by |
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
⌛ Testing commit 9e1fcaf with merge 17696a62295df34fd4a02bc6bb1812cfeae19a26... |
💔 Test failed - checks-actions |
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
The job Click to see the possible cause of the failure (guessed by this bot)
|
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.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
#[expect]
attribute (RFC 2383) #95542 (Support tool lints with the#[expect]
attribute (RFC 2383))append_place_to_string
from recursion into iteration #96733 (turnappend_place_to_string
from recursion into iteration)Vec
fields #96760 (diagnostics: port more diagnostics to derive + add support forVec
fields)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup