fix(linter/require-await): skip comments when searching for token

[camc314]

No description provided.

[camc314]

• fix(linter/no-empty-named-blocks): skip comments when searching for token #15735
• fix(linter/require-await): skip comments when searching for token #15734 👈 (View in Graphite)
• fix(linter/no-async-await): skip comments when searching for token #15733
• fix(linter/consistent-type-specifier-style): skip comments when searching for token #15732
• 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.

[codspeed-hq]

CodSpeed Performance Report

Merging #15734 will not alter performance

_{Comparing c/11-15-fix_linter_require-await_skip_comments_when_searching_for_token (042befd) with main (7a78220)¹}

Summary

✅ 4 untouched
⏩ 33 skipped²

Footnotes

1. No successful run was found on main (042befd) during the generation of this report, so 7a78220 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 33 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[graphite-app]

Merge activity

• Nov 15, 8:04 PM UTC: camc314 added this pull request to the Graphite merge queue.
• Nov 15, 8:08 PM UTC: Merged by the Graphite merge queue.

[overlookmotel]

Was this one necessary? Function's span wouldn't include a leading comment.

Oh maybe it's required for this case (if this code deals with methods):

class C {
  static /* async */ async method() {}
}

[overlookmotel]

Shit! What about decorators?

class C {
  @haha_gotcha('async')
  async method() {}
}

[camc314]

class C {
  @haha_gotcha('async')
  async method() {}
}

f*** I didn't think about this. I was hoping that a simple search, and check that we're not inside comments would be good enought. I guess not 😞 , we may actiually need tokens (or re-tokenize them) from the parser.

[camc314]

Was this one necessary? Function's span wouldn't include a leading comment.

Oh maybe it's required for this case (if this code deals with methods):

class C {
  static /* async */ async method() {}
}

Possibly not neeed actuallly. But i think it's good practive to start using the find next token api rather than manual string search. It just reduces the risk of producing diagnostics on the wrong things

[overlookmotel]

class C {
  @haha_gotcha('async')
  async method() {}
}

f*** I didn't think about this. I was hoping that a simple search, and check that we're not inside comments would be good enought. I guess not 😞 , we may actiually need tokens (or re-tokenize them) from the parser.

We can avoid re-tokenizing by starting the search from func.decorators.last().map(|dec| dec.span.end).unwrap_or_else(|| func.span.start).

Even if we did re-tokenize, I don't think it would help. e.g. in this case you'd get the wrong async token:

class C {
  @dec(async () => {})
  static async method() {}
}

Or could search backwards from func.id.span.start - 5.

[camc314]

If we start doing searches like that, they're getting ** really ** specific and nuanced. Might just be easier to use codegen in that case.

[overlookmotel]

use codegen in that case

How do you mean?

[camc314]

use codegen in that case

How do you mean?

Look at:

oxc/crates/oxc_linter/src/rules/unicorn/prefer_class_fields.rs

Lines 135 to 150 in 85bd19a

	ctx.diagnostic_with_suggestion(prefer_class_fields_suggestion(assign.span), |fixer| {
	let fixer = fixer.for_multifix();
	let mut fix = fixer.new_fix_with_capacity(2);
	// Remove the assignment from constructor
	fix.push(fixer.delete(&**expr_stmt));
	// Replace existing property value
	if let Some(value) = &prop.value {
	let mut codegen = fixer.codegen();
	codegen.print_expression(&assign.right);
	fix.push(fixer.replace(value.span(), codegen.into_source_text()));
	}
	fix.with_message("Replace `this` assignment with class field declaration")
	});

We can basically write stuff like:

            ctx.diagnostic_with_suggestion(prefer_class_fields_suggestion(assign.span), |fixer| {
                    let mut codegen = fixer.codegen();
                    codegen.print_expression(&assign.right);
            });

Which use oxc_codegen to print the code (i think comments will be lost though).