feat(linter): add eslint/no-misleading-character-class

[Sysix]

closes #614
related #479

https://eslint.org/docs/latest/rules/no-misleading-character-class

The rule is still in nursery because of two problems:

• regexp: UnicodeEscape Character inside StringLiteral is not correctly detected #13660
• linter: respect second flags of new RegExp(/ab/u, "i") #13436

The spans for emojis are wrong too, do not know if the rule should fix this, or the regexp parser.

[Sysix]

• feat(linter): add eslint/no-misleading-character-class #13365 👈 (View in Graphite)
• 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 Instrumentation Performance Report

Merging #13365 will not alter performance

_{Comparing 08-22-feat_linter_add_eslint_no-misleading-character-class_ (8221a01) with main (57108c0)¹}

Summary

✅ 37 untouched

Footnotes

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

[leaysgur]

After checking, I think it doesn't seem to be an issue only for the regexp AST at least.

Please look at the following code.

#![expect(clippy::print_stdout)]
use oxc_allocator::Allocator;
use oxc_diagnostics::{GraphicalReportHandler, OxcDiagnostic};
use oxc_parser::Parser;
use oxc_span::SourceType;

fn main() {
    // Test cases with various Unicode characters
    let test_cases = vec![
        // Regular expressions
        r"let r1 = /[👍]/;",
        r"let r2 = /[❇️]/;",
        r"let r3 = /[🇯🇵]/;",
        r"let r4 = /[Á]/;",
        r"let r5 = /[abc]/;",
        r"let r6 = /[日本語]/;",
        r"let r7 = /[👨‍👩‍👦]/;",
        // String literals for comparison
        r#"let s1 = "[👍]";"#,
        r#"let s2 = "[❇️]";"#,
        r#"let s3 = "[🇯🇵]";"#,
        r#"let s4 = "[Á]";"#,
        r#"let s5 = "[abc]";"#,
        r#"let s6 = "[日本語]";"#,
        r#"let s7 = "[👨‍👩‍👦]";"#,
    ];

    let allocator = Allocator::default();
    let source_type = SourceType::default();

    for source_text in test_cases {
        println!("Source: {source_text}");

        let ret = Parser::new(&allocator, source_text, source_type).parse();

        // Report diagnostic for each regex literal or string literal
        for node in ret.program.body {
            use oxc_ast::ast::*;

            if let Statement::VariableDeclaration(decl) = &node {
                for declarator in &decl.declarations {
                    if let Some(init) = &declarator.init {
                        let span = match init {
                            Expression::RegExpLiteral(regex) => regex.span,
                            Expression::StringLiteral(string) => string.span,
                            _ => continue,
                        };

                        // Create a diagnostic to show how the span is rendered
                        let diagnostic = OxcDiagnostic::warn("Test span rendering")
                            .with_label(span)
                            .with_source_code((*source_text).to_string());

                        // Render the diagnostic
                        let mut output = String::new();
                        let handler = GraphicalReportHandler::new();
                        handler.render_report(&mut output, diagnostic.as_ref()).unwrap();

                        println!("{output}");
                    }
                }
            }
        }
    }
}

And the result is as follows.

Even the string literal isn't reported correctly.

Perhaps there's a problem on the oxc-miette side...?

[camc314]

Perhaps there's a problem on the oxc-miette side...?

this seems likley, when rendering the span i guess it doesn't understand that the emojis are amoji sequences

[camc314]

Let's fix the spans later

[Sysix]

Thanks for the fix! Updated the PR

[camc314]

I moved this to directly target main. I'll get miette fixed first, then we can bump it and fix the spans

[camc314]

Merge activity

• Sep 18, 7:59 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Sep 18, 8:03 AM UTC: camc314 added this pull request to the Graphite merge queue.
• Sep 18, 8:08 AM UTC: Merged by the Graphite merge queue.