Rollup of 10 pull requests #126910
Closed
Rollup of 10 pull requests #126910
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
The `error-format=short` output only displays the path, error code and main error message all in the same line. We now add the primary span label as well after the error message, to provide more context.
…enum-with-debug, r=pnkfelix Show notice about "never used" of Debug for enum Close rust-lang#123068 If an ADT implements `Debug` trait and it is not used, the compiler says a note that indicates intentionally ignored during dead code analysis as [this note](https://github.com/rust-lang/rust/blob/2207179a591f5f252885a94ab014dafeb6e8e9e8/tests/ui/lint/dead-code/unused-variant.stderr#L9). However this node is not shown for variants that have fields in enum. This PR fixes to show the note.
…dtwco Add `rust_analyzer` as a predefined tool Given all the other rust-lang tools have it, I'd expect r-a to have it too. (we have a few ideas for using this rust-lang/rust-analyzer#11556).
…li-obk transmute size check: properly account for alignment Fixes another place where ZST alignment was ignored when checking whether something is a newtype. I wonder how many more of these there are... Fixes rust-lang#101084
compiletest: make the crash test error message abit more informative r? `@oli-obk`
…nkfelix Mark assoc tys live only if the corresponding trait is live r? `@pnkfelix`
…, r=compiler-errors Ensure we don't accidentally succeed when we want to report an error This also changes the `DefiningOpaqueTypes::No` to `Yes` without adding tests, as it is solely run on the error path to improve diagnostics. I was unable to provide a test that changes diagnostics, as all the tests I came up with ended up successfully constraining the opaque type and thus succeeding the coercion. r? `@compiler-errors` cc rust-lang#116652
…, r=davidtwco On short error format, append primary span label to message The `error-format=short` output only displays the path, error code and main error message all in the same line. We now add the primary span label as well after the error message, to provide more context.
not use offset when there is not ends with brace Fixes rust-lang#126764
Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level I have been tangling with precedence as part of porting some pretty-printer improvements from syn back to rustc (related to parenthesization of closures, returns, and breaks by the AST pretty-printer). As far as I have been able to tell, there is no difference between the 2 different precedence levels that rustc identifies as `PREC_POSTFIX` (field access, square bracket index, question mark, method call) and `PREC_PAREN` (loops, if, paths, literals). There are a bunch of places that look at either `prec < PREC_POSTFIX` or `prec >= PREC_POSTFIX`. But there is nothing that needs to distinguish PREC_POSTFIX and PREC_PAREN from one another. https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast/src/util/parser.rs#L236-L237 https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L2829 https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L1290 In the interest of eliminating a distinction without a difference, this PR collapses these 2 levels down to 1. There is exactly 1 case where an expression with PREC_POSTFIX precedence needs to be parenthesized in a location that an expression with PREC_PAREN would not, and that's when the receiver of ExprKind::MethodCall is ExprKind::Field. `x.f()` means a different thing than `(x.f)()`. But this does not justify having separate precedence levels because this special case in the grammar is not governed by precedence. Field access does not have "lower precedence than" method call syntax — you can tell because if it did, then `x.f[0].f()` wouldn't be able to have its unparenthesized field access in the receiver of a method call. Because this Field/MethodCall special case is not governed by precedence, it already requires special handling and is not affected by eliminating the PREC_POSTFIX precedence level. https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast_pretty/src/pprust/state/expr.rs#L217-L221
…r=davidtwco Suggest inline const blocks for array initialization rust-lang#126894
rustbot
added
A-meta
|
|
bors
added
S-waiting-on-bors
|
#125241 seems to be already merged. |
|
oh wut, weird. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
rust_analyzeras a predefined tool #125241 (Addrust_analyzeras a predefined tool)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup