[autofix.ci] apply automated fixes

crates/oxc_linter/src/rules/jsdoc/check_access.rs

@@ -25,7 +25,7 @@ pub struct CheckAccess;
 
 declare_oxc_lint!(
     /// ### What it does
-    /// 
+    ///
     /// Checks that `@access` tags use one of the following values:
     /// - "package", "private", "protected", "public"
     ///
@@ -34,7 +34,7 @@ declare_oxc_lint!(
     /// - Use of multiple instances of `@access` (or the `@public`, etc) on the same doc block.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// It is important to have a consistent way of specifying access levels.
     ///
     /// ### Examples

crates/oxc_linter/src/rules/jsdoc/check_property_names.rs

@@ -20,11 +20,11 @@ pub struct CheckPropertyNames;
 
 declare_oxc_lint!(
     /// ### What it does
-    /// 
+    ///
     /// Ensures that property names in JSDoc are not duplicated on the same block and that nested properties have defined roots.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// `@property` tags with the same name can be confusing and may indicate a mistake.
     ///
     /// ### Examples

crates/oxc_linter/src/rules/jsdoc/check_tag_names.rs

@@ -19,12 +19,12 @@ pub struct CheckTagNames(Box<CheckTagnamesConfig>);
 
 declare_oxc_lint!(
     /// ### What it does
-    /// 
+    ///
     /// Reports invalid block tag names.
     /// Additionally checks for tag names that are redundant when using a type checker such as TypeScript.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// Using invalid tags can lead to confusion and make the documentation harder to read.
     ///
     /// ### Examples

crates/oxc_linter/src/rules/oxc/no_accumulating_spread.rs

@@ -76,11 +76,11 @@ pub struct NoAccumulatingSpread;
 
 declare_oxc_lint!(
     /// ### What it does
-    /// 
+    ///
     /// Prevents using object or array spreads on accumulators in `Array.prototype.reduce()` and in loops.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// Object and array spreads create a new object or array on each iteration.
     /// In the worst case, they also cause O(n) copies (both memory and time complexity).
     /// When used on an accumulator, this can lead to `O(n^2)` memory complexity and

crates/oxc_linter/src/rules/typescript/consistent_indexed_object_style.rs

@@ -28,11 +28,11 @@ enum ConsistentIndexedObjectStyleConfig {
 
 declare_oxc_lint!(
     /// ### What it does
-    /// 
+    ///
     /// Require or disallow the `Record` type.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// Inconsistent style for indexed object types can harm readability in a project.
     ///
     /// ### Examples

crates/oxc_linter/src/rules/unicorn/no_unreadable_iife.rs

@@ -19,11 +19,11 @@ pub struct NoUnreadableIife;
 
 declare_oxc_lint!(
     /// ### What it does
-    /// 
+    ///
     /// This rule disallows IIFEs with a parenthesized arrow function body.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// IIFEs with a parenthesized arrow function body are unreadable.
     ///
     /// ### Examples

crates/oxc_linter/src/rules/unicorn/no_useless_undefined.rs

@@ -32,11 +32,11 @@ impl Default for NoUselessUndefined {
 
 declare_oxc_lint!(
     /// ### What it does
-    /// 
+    ///
     /// Do not use useless `undefined`.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// `undefined` is the default value for new variables, parameters, return statements, etc… so specifying it doesn't make any difference.
     ///
     /// ### Examples

crates/oxc_linter/src/rules/unicorn/number_literal_case.rs

@@ -38,11 +38,11 @@ pub struct NumberLiteralCase;
 
 declare_oxc_lint!(
     /// ### What it does
-    /// 
+    ///
     /// This rule enforces proper case for numeric literals.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// When both an identifier and a number literal are in lower case, it can be hard to differentiate between them.
     ///
     /// ### Examples

crates/oxc_linter/src/rules/unicorn/prefer_prototype_methods.rs

@@ -28,7 +28,7 @@ declare_oxc_lint!(
     /// This rule prefers borrowing methods from the prototype instead of the instance.
     ///
     /// ### Why is this bad?
-    /// 
+    ///
     /// “Borrowing” a method from an instance of `Array` or `Object` is less clear than getting it from the corresponding prototype.
     ///
     /// ### Examples