refactor(oxc): apply clippy::use_self

[Boshen]

No description provided.

[Boshen]

• refactor(oxc): apply clippy::use_self #9240 👈 (View in Graphite)
• fix(minifier): fix clippy::suspicious_operation_groupings warning #9238
• docs(oxc): enable clippy::too_long_first_doc_paragraph #9237
• fix(codegen): fix clippy::unused_peekable warning #9236
• fix(transformer): fix clippy::iter_on_single_items warning #9235
• fix(language_server): fix clippy::significant_drop_in_scrutinee warning #9234
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[graphite-app]

Merge activity

• Feb 19, 11:22 AM EST: A user added this pull request to the Graphite merge queue.
• Feb 19, 11:25 AM EST: The Graphite merge queue couldn't merge this PR because it had conflicts with the trunk branch.

[codspeed-hq]

CodSpeed Performance Report

Merging #9240 will not alter performance

_{Comparing 02-20-refactor_ast_tools_generate_self_clippy_use_self_ (71b2e33) with main (3414824)}

Summary

✅ 33 untouched benchmarks

[overlookmotel]

I'm not sure if I like this lint.

In some cases, using Self is a big improvement, like here:

impl Serialize for AssignmentOperator {
    fn serialize<S: Serializer>(&self, serializer: S) -> Result<S::Ok, S::Error> {
        match self {
-           AssignmentOperator::Assign => {
-               serializer.serialize_unit_variant("AssignmentOperator", 0, "=")
-           }
-           AssignmentOperator::Addition => {
-               serializer.serialize_unit_variant("AssignmentOperator", 1, "+=")
-           }
-           AssignmentOperator::Subtraction => {
-               serializer.serialize_unit_variant("AssignmentOperator", 2, "-=")
-           }
+           Self::Assign => serializer.serialize_unit_variant("AssignmentOperator", 0, "="),
+           Self::Addition => serializer.serialize_unit_variant("AssignmentOperator", 1, "+="),
+           Self::Subtraction => serializer.serialize_unit_variant("AssignmentOperator", 2, "-="),

But sometimes explicit type makes for clearer code, like this one:

impl<'alloc> String<'alloc> {

    // ...
    // 120 lines of code
    // ...

    pub unsafe fn from_raw_parts_in(
        buf: *mut u8,
        length: usize,
        capacity: usize,
        allocator: &'alloc Allocator,
-   ) -> String<'alloc> {
+   ) -> Self {

There's 2 reasons I think String<'alloc> is preferable here:

1. There's 120 lines between where Self is defined, and where it's used, so when you're looking at fn from_raw_parts_in, you need to scroll up to find out what Self is (VSCode helps with this, but no such help when reviewing a PR on Github).
2. String<'alloc> makes it clearer that the lifetime in param &'alloc Allocator and return value String<'alloc> are related. &'alloc Allocator -> Self hides that relationship.

In my view, I think it'd be preferable to cherry-pick the good parts from this PR, but keep the lint rule disabled. Doing that wouldn't take long.

I've reviewed since you requested that I do. But if you feel differently, merge it!

[overlookmotel]

Hahaha you didn't actually request a review! It was just Github requesting my review as a "code owner". Oh well, that's my opinion anyway...

[Boshen]

This rule is pretty annoying, we don't have the muscle memory to always apply Self, which ends up with a cycle of lint, change and commit - a bit of time wasted.

And I think applying Self hinders readability in most cases.

Hence I'm going to nuke this rule given the bad dx.