Use Rule for FileNoqaDirectives

[ntBre]

Summary

See #18946 (comment).

Test Plan

Existing tests

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #18966 will not alter performance

_{Comparing brent/directive-rule (2bbc37e) with brent/string-noqa-code (4eab76b)}

Summary

✅ 37 untouched benchmarks
⁉️ 1 dropped benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⁉️	ty_micro[many_attribute_assignments]	56.6 ms	N/A	N/A

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

I've a small perf recommendation to reduce the number of Rule::parse call

[MichaReiser]

Do we have a short-circuit path somewhere that skips iterating over all diagnostics if there are no noqa codes at all?

[ntBre]

I don't think so, but that's a good idea. I added

    if file_noqa_directives.is_empty() && noqa_directives.is_empty() {
        return Vec::new();
    }

to the top of this function, along with those two is_empty methods.

[MichaReiser]

Should we add (or use) a method includes_code that accepts a secondary code instead of the rule. That would allow us to defer the rule parsing up to the point where we've found a suppression comment (which should be the exception).

To avoid calling Noqa::to_string, we can add a method Noqa::matches_code(code: &str) which can match the string without allocationg

[ntBre]

Ah yeah, I already added FileExemption::contains_secondary_code but I can call it before this to bail out earlier without parsing the rule code.

[MichaReiser]

Hmm, I think I would have merged this into main or waited with merging to make it easier to review #18946 It's no big deal. It's just a bit confusing and distracting because I now need to decide for each change if I already reviewed it or not.

The other advantage of merging to main is that it would give us better insight in how #18946 changes performance. Now it's all muddled up with this change.

[ntBre]

Oh, sorry about that! I wasn't thinking about the review or checking the benchmarks again, but it sounds obvious in hindsight.