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.
d49994b060/compiler/rustc_ast/src/util/parser.rs (L236-L237)d49994b060/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs (L2829)d49994b060/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.
d49994b060/compiler/rustc_ast_pretty/src/pprust/state/expr.rs (L217-L221)
ast: Standardize visiting order for attributes and node IDs
This should only affect `macro_rules` scopes and order of diagnostics.
Also add a deprecation lint for `macro_rules` called outside of their scope, like in https://github.com/rust-lang/rust/issues/124535.
Cache lintcheck binary in ci
Always trims ~40s off the `diff` job as it no longer needs to install the rust toolchain or compile lintcheck. Saves a further ~20s for the `base`/`head` jobs when the cache is warm
It now uses artifacts for restoring the JSON between jobs as per https://github.com/rust-lang/rust-clippy/pull/10398#discussion_r1642364392, cc `@flip1995`
The lintcheck changes are to make `./target/debug/lintcheck` work, running `cargo-clippy`/`clippy-driver` directly doesn't work without `LD_LIBRARY_PATH`/etc being set which is currently being done by `cargo run`. By merging the `--recursive` and normal cases to both go via regular `cargo check` we can have Cargo set up the environment for us
r? `@xFrednet`
changelog: none
use short message format in integration test
While checking #12983, bors came upon a cargo change that put "E0463" into the standard error (as part of a test case code snippet), which the integration test picked up to fail the build. Talk about unforeseen consequences.
So this PR just changes the integration test to use short message format in order to not include the code snippets in the output. Hopefully that will fix the problem.
r? `@Alexendoo`
---
changelog: none
resolve `clippy::invalid_paths` on `bool::then`
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: none
Fix `...` in multline code-skips in suggestions
When we have long code skips, we write `...` in the line number gutter.
For suggestions, we were "centering" the `...` with the line, but that was inconsistent with what we do in every other case *and* off-center.
Fix incorrect suggestion for `manual_unwrap_or_default`
Fixes#12928.
If this not a "simple" pattern, better not emit the lint.
changelog: Fix incorrect suggestion for `manual_unwrap_or_default`
When we have long code skips, we write `...` in the line number gutter.
For suggestions, we were "centering" the `...` with the line, but that was consistent with what we do in every other case.
This removes the ICE codepaths for `f16` and `f128` in Clippy.
`rustc_apfloat` is used as a dependency for the parsing of these types,
since their `FromStr` implementation will not be available in the
standard library for a while.
Add more types to `is_from_proc_macro`
I've been running through going through all the lint implementations to clean them up. I'll be separating out the changes into small PRs to make reviewing easier.
changelog: none
Add myself back to reviewer rotation
Hey 👋
Even though I might have less time than usual, $DAY_JOB soon and working on Cosmographic Software for fun, I think I want to get back in the swing of things here
changelog: none
Lint `manual_unwrap_or` for it let cases
This PR modifies `manual_unwrap_or` to lint for `if let` cases as well. This effort is part of the fixes desired by https://github.com/rust-lang/rust-clippy/issues/12618
changelog:[`manual_unwrap_or`]: Lint for `if let` cases.
Rework `octal_escapes`
Main changes are not doing UTF-8 decoding, noting each occurrence as an individual lint emission, and narrowing the span to point to the escape itself.
changelog: none
Fix ICE in `upper_case_acronyms`
fixes#12284
The logic has been rewritten to avoid allocations. The old version allocated multiple vecs and strings for each identifier. The new logic allocates a single string only when the lint triggers.
This also no longer lints on strings which don't start with an uppercase letter (e.g. `something_FOO`).
changelog: none
Pause assignments to @xFrednet for summer break 🏖️
I'm only removing myself from the assignment roulette as I want to allow `r? xFrednet` for `gh-pages` and other updates. So feel free to still `r?` me.
r? `@ghost`
changelog: none
I'm only removing myself from the assignment roulette as I want to allow `r? xFrednet` for `gh-pages` and other updates. So feel free to still `r?` me.
