Add checking for unnecessary delims in closure body

[chenyukang]

Fixes #136741

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[chenyukang]

any better check for this?
seems the AST generated by contracts are the same with normal closures.

[oli-obk]

we could generate an #[allow] for this lint as part of the ast we generate. Alternatively you could check that it's expanded code in general and just ignore all of this. Likely some macros will hit this issue, too (add a test for that, too)

[chenyukang]

Alternatively you could check that it's expanded code in general and just ignore all of this.

The following check here https://github.com/rust-lang/rust/pull/136906/files#diff-e25b2c6c1fa434ab8078db81003888370f06b9da5503d1590757350be8e31103L945-L946 already checked it?

I also tried to use closure.body.span.can_be_used_for_suggestions(), seems can not exclude this scenario.

[chenyukang]

for the solution we could generate an #[allow] for this lint as part of the ast we generate.

I tried to add it here:
428b251

which will break the parser.

seems we only add simple tokentree for the contract and parse it here:
https://github.com/chenyukang/rust/blob/428b251feb3e87e41c9e46656cc96a3b94d88ea5/compiler/rustc_parse/src/parser/generics.rs#L302-L325

we do not expect too much change just to generate an #[allow(unused_parens)], where is the proper point to inject it.

[oli-obk]

already checked it?

ah that means contract expansion doesn't add the expansion info to the spans. I did indeed forget to check for that at all when it was introduced

cc @celinval

[chenyukang]

I tried to mark the span with DesugaringKind::Contract at here: https://github.com/chenyukang/rust/blob/9ec13a62cafd1448b2d43d887034ae6501fca6d0/compiler/rustc_ast_lowering/src/item.rs#L1082-L1089

But found that early lint check is run before this point.

I think this solution with span check maybe enough: 64f1f52

the generated closure span are all the same, which is different from real code.

[oli-obk]

Ah right this is due to the macro expansion from

rust/compiler/rustc_builtin_macros/src/contracts.rs

Line 47 in f78099e

fn expand_contract_clause(

maybe the span can be annotated there?

[chenyukang]

I tried to follow mark_with_reason https://github.com/chenyukang/rust/blob/59281e98d0af7ed5071d141235ce5ddff1f60253/compiler/rustc_span/src/hygiene.rs#L906-L919

to create a span with annotation:
59281e9#diff-0843065cebe8379cca975e505c67c393f9933c8d9019fb6a6e3b3d5654157bc1R70

The problem is how can we get a ctx which meet the trait here, seems we're at a very early stage:

error[E0277]: the trait bound `SyntaxContext: rustc_span::HashStableContext` is not satisfied
   --> compiler/rustc_builtin_macros/src/contracts.rs:70:49
    |
70  |     let expn_id = LocalExpnId::fresh(expn_data, attr_span.ctxt());
    |                   ------------------            ^^^^^^^^^^^^^^^^ the trait `rustc_span::HashStableContext` is not implemented for `SyntaxContext`
    |                   |
    |                   required by a bound introduced by this call
    |
note: required by a bound in `LocalExpnId::fresh`
   --> /Users/yukang/rust/compiler/rustc_span/src/hygiene.rs:200:53
    |
200 |     pub fn fresh(mut expn_data: ExpnData, ctx: impl HashStableContext) -> LocalExpnId {
    |                                                     ^^^^^^^^^^^^^^^^^ required by this bound in `LocalExpnId::fresh`

[chenyukang]

I think the span checking here is enough for avoid lint for contract syntax here?
https://github.com/rust-lang/rust/pull/136906/files#diff-e25b2c6c1fa434ab8078db81003888370f06b9da5503d1590757350be8e31103R917-R918

it's a bit hacky, but user written code will always true on : e.span != closure.body.span.

And also considering the fact that contract syntax is temporary, if we can not find a perfect way to mark the span we should not introduce more change for it. #137134 (comment)

[oli-obk]

You're absolutely right. Sorry for holding it up

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in coverage instrumentation.

cc @Zalathar

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[oli-obk]

that's a lot of changes in unrelated tests. Changing tests for such reasons isn't too great and the value of this change in tests isn't really there either. Maybe add the lint to the list of lints that compiletest allows for all tests?

[jieyouxu]

That's a lot of changes in unrelated tests. Changing tests for such reasons isn't too great and the value of this change in tests isn't really there either.

IMO we may want to just not warn on this case. Looking at the diffs both in the compiler and in the tests, it doesn't seem like a strict readability improvement to me (at times I find it even a bit harder to read). unused_parens is also a warn-by-default lint, so we'd be warning on a lot of existing code (judging by quite a few instances of compiler code getting newly linted on when we expand this lint).

Maybe add the lint to the list of lints that compiletest allows for all tests?

I think we should avoid adding blanket allows for all tests where feasible (many tests getting affected is itself a decent indicator, albeit rough, for if a change may impact a lot of cases).

[oli-obk]

Looking at the diffs both in the compiler and in the tests, it doesn't seem like a strict readability improvement to me (at times I find it even a bit harder to read)

in the compiler and tools it was always an improvement to me. What specific examples do you dislike?

[jieyouxu]

in the compiler and tools it was always an improvement to me. What specific examples do you dislike?

This probably comes down to personal preference, but I don't really find these specific examples to be strictly better (I find the { } helps with visual separation of the body expr. I don't feel too strongly about this so 🤷

-.all(|(node, span_edge)| { span_edge.is_some() <= self.is_supernode(node) }),
+.all(|(node, span_edge)| span_edge.is_some() <= self.is_supernode(node)),

-write!(&mut counter, "{:#}", fmt::from_fn(|f| { self.inner_full_print(None, f, cx) }))
+write!(&mut counter, "{:#}", fmt::from_fn(|f| self.inner_full_print(None, f, cx)))

Removing parens on the very short exprs do look more readable to me. So I guess I feel mixed about it? lol

[jieyouxu]

Since you're already looking at it... r? @oli-obk

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[chenyukang]

that's a lot of changes in unrelated tests. Changing tests for such reasons isn't too great and the value of this change in tests isn't really there either. Maybe add the lint to the list of lints that compiletest allows for all tests?

done with commit 3a34ad7

[chenyukang]

Yes, this seems comes down to personal preference, but I just found rustfmt will remove the braces in this closure:

 let some_predicate = |x: &mut i32| { *x == 2 || *x == 3 || *x == 6 };

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

[chenyukang]

rust-lang/rust-analyzer#20122 is merged, rebase and try again...

[lnicola]

@chenyukang feel free to patch this here instead.

[chenyukang]

@chenyukang feel free to patch this here instead.

yeah, seems rust-analyzer haven't synced up, CI is ok now.

@rustbot ready

[oli-obk]

@bors r+ rollup

[bors]

📌 Commit 4dc954f has been approved by oli-obk

It is now in the queue for this repository.

[Kobzol]

@rust-timer build 936033a

Checking for #143731.

[rust-timer]

Finished benchmarking commit (936033a): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.1%, 0.4%]	11
Regressions ❌ (secondary)	0.3%	[0.1%, 0.9%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.1%, 0.4%]	11

Max RSS (memory usage)

Results (primary 1.2%, secondary -0.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.2%	[0.6%, 3.6%]	7
Regressions ❌ (secondary)	4.2%	[2.0%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.3%	[-6.0%, -2.3%]	3
All ❌✅ (primary)	1.2%	[0.6%, 3.6%]	7

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 463.013s -> 465.296s (0.49%)
Artifact size: 374.51 MiB -> 374.53 MiB (0.01%)

[Kobzol]

Looks like this is the source of the small regression from #143731. Any ideas about clawing that back? Or do you think it's expected since we do more work Oli?